Re: Second RewriteQuery complains about first RewriteQuery in edge case - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Second RewriteQuery complains about first RewriteQuery in edge case
Date
Msg-id 132240.1764262521@sss.pgh.pa.us
Whole thread Raw
In response to Re: Second RewriteQuery complains about first RewriteQuery in edge case  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Second RewriteQuery complains about first RewriteQuery in edge case
List pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> Yes, I think that would work, but I think a simpler solution would be
> to just have RewriteQuery() track which CTEs it had already rewritten,
> which can be done just by passing around a list of CTE names.
> Something like the attached.

Hmmm ... I don't love this particular implementation, because it
is doubling down on the already-undesirable assumption that the
rule CTEs have no name conflicts with the outer query's CTEs.
Still, unless somebody sets out to remove that restriction,
it won't matter.  (It'd be a good idea for the comments here
to point that out though.)

I do think there's another way we could attack it.  Similarly
to the way VALUES RTEs are either processed or skipped by
checking the rangetable length, we could pass down the length
of the outer query's cteList, and assume that the last N entries
in a product query's cteList have already been processed.
(Last N not first N because of the order in which the lists are
concatenated at line 596.)  Maybe that's too fragile, but the
approach seems to have worked all right for VALUES.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: weird ON CONFLICT clauses
Next
From: Antonin Houska
Date:
Subject: Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements