Skip site navigation (1) Skip section navigation (2)

Re: Questions about parser code

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Questions about parser code
Date: 2007-01-30 18:35:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
So I have basic non-recursive queries working. However currently it's
essentially inlining the subquery at every call-site which obvious will never
handle recursive queries and in fact doesn't even do what people expect from
the basic syntax. The use case for the WITH syntax is when you have an
expensive query you want to avoid calling multiple times from within your

postgres=#  with frotz(a) as (select * from x) select * from frotz,frotz as x(b);
 a | b 
 1 | 1
 1 | 2
 2 | 1
 2 | 2
(4 rows)

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> Is it ok to scribble on and reuse objects from the parse tree when generating
>> the transformed tree? Or should the transformed query object be built from
>> freshly allocated nodes?
> We do both already; take your pick.  If you do the former, though,
> I suggest designing the code so that it's a no-op on an
> already-transformed node.  It used to be the case that the grammar
> could generate multiple references to the same subtree (e.g., by
> transforming "x BETWEEN y AND z" to "x >= y AND x <= z") and I'm not
> sure we have removed all such shortcuts.

I was wondering whether it was necessary to copy the alias node from an
existing node or if I could just create more references to it.

> There's some logical cleaniness to using different node types for raw
> and transformed trees, but when there's a simple one-for-one
> correspondence this is probably overkill.

Currently I'm storing a lit of RangeSubselects in the pstate. That just
happened to be a node with an alias and a subquery which is what I needed. I
was considering replacing the SelectStmt node with a Query node directly
instead of creating a new RangeSubselect node.

However now I'm thinking I probably need to do something more complicated. As
it is there's no way to tell when I add a rangetable to a query that it came
from a subquery in the common table expression list in the pstate instead of
from an inlined subquery.

  Gregory Stark

In response to

pgsql-hackers by date

Next:From: imadDate: 2007-01-30 18:59:05
Subject: PL/pgSQL RENAME functionality in TODOs
Previous:From: Mike RylanderDate: 2007-01-30 18:23:32
Subject: Re: [HACKERS] "May", "can", "might"

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group