From: | Mark Cave-Ayland <mark(dot)cave-ayland(at)ilande(dot)co(dot)uk> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: WIP: Hierarchical Queries - stage 1 |
Date: | 2006-09-22 07:29:00 |
Message-ID: | 1158910140.8379.27.camel@mca-desktop |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Hi Tom,
Thanks for your initial thoughts on this.
On Wed, 2006-09-20 at 20:13 -0400, Tom Lane wrote:
(cut)
> 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.
For semantic reasons, I can see why you are questioning whether or not
the CTE should be contained within the rangetable - there is an implicit
hint that RTEs reflect entries within the FROM clause, but then I also
see that the rewriter adds RTEs when substituting view definitions into
queries. The comments in parsenodes.h also suggest that an RTE is a
namespace/data source reference for a named entity within the query.
The main problem I can see with keeping the CTEs outside the rangetable
is that according to the source, jointree nodes must currently have
RANGETBLREF nodes as leaf nodes; as I understand it, your suggestion of
maintaining the CTEs separately would involve something along the lines
of keeping a separate CTETable and creating some form of CTETBLREF node
that could be referenced within the jointree. While arguably it may be
semantically neater, it appears to involve quite a bit of extra work...
could you explain in more detail as to why you feel that CTEs should
remain outside the rangetable?
> 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.
This is effectively what the patch does, albeit not particularly
elegantly. I'll spend some time on making those changes a bit more
refined.
Kind regards,
Mark.
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Schaber | 2006-09-22 07:58:19 | Re: Index bloat problem in 7.4 |
Previous Message | Tom Lane | 2006-09-22 05:06:09 | Re: pg_upgrade: downgradebility |
From | Date | Subject | |
---|---|---|---|
Next Message | Joachim Wieland | 2006-09-22 11:06:35 | Timezone doc patch |
Previous Message | Tom Lane | 2006-09-21 16:17:28 | Re: [HACKERS] large object regression tests |