Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> writes:
> My main issue at the moment is that the code in transformFromClauseItem
> seems a terrible hack, mainly because the grammar returns each string
> within the FROM clause as a RangeVar, and transformFromClauseItem
> assumes that each RangeVar represents a physical relation. Of course,
> this is not the case when referencing a CTE and so the code first checks
> to see if an entry has already been created when processing the WITH
> clause; if it does then we return NULL to indicate that
> transformFromClause should do nothing. Messy, but I wanted to see what
> other developers thought before jumping in and rewriting this part of
> the code.
You really can't get away with having the identical representation for
CTEs and ordinary sub-selects in the range table. For instance, it
looks like your patch will think that
select ... from (select ...) as x, x, ...
is legal when it certainly is not. I think you need either a new
RTEKind or an additional flag in the RTE to show that it's a CTE rather
than a plain subselect. I'm not entirely sure that you even want the
CTEs in the rangetable at all --- that still needs some thought.
> Another point to think about is what should a query return if the SELECT
> doesn't refer to a CTE?
The spec ought to make this perfectly clear ... or perhaps not so clear,
but I'm sure it's defined.
> - with myrel(p1) as (select oid from pg_class) select myrel.p1 from
> myrel AS foo, pg_class AS bar WHERE foo.p1 = bar.oid; -- FAILS
> So in this case, should foo be accepted as a valid alias for myrel?
This comes back to the question of whether the CTE per se should be an
RTE at all. Maybe only the reference to it should be an RTE. The
behavior when seeing a plain RangeVar in FROM would be to first search
the side list of valid CTEs, and only on failure go looking for a real
table.
regards, tom lane