Re: Status of Hierarchical Queries

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Status of Hierarchical Queries
Date: 2007-02-21 20:56:09
Message-ID: 87d543p6vq.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:

> As was discussed in several threads, I'd handed over the
> responsibility of hierarchical queries to Greg Stark several weeks
> ago. He posted a preliminary patch which I don't believe anyone
> looked at. For 8.3's sake, I wanted to make sure we get the status of
> this out on the table so there won't be any surprises like those
> related to 8.2.
>
> Where are we at?

The preliminary patch didn't actually do anything recursive. It handled
non-recursive WITH clauses by directly inlining the subquery as if it were a
subquery RangeTable.

Now that's not entirely useless, it's a handy syntactic sugar for having to
write the same query multiple times.

> Has anyone reviewed the preliminary work? Any comments, suggestions, etc?

I had asked questions about whether people thought the places where I was
storing the state were appropriate. I'm not entirely clear on what types of
state should live in the pstate versus in the parse tree versus elsewhere.

Specifically I asked about a problem where I thought using the pstate to store
the scope of the cte names would give the right semantics where they get
inherited by subqueries but pass out of scope for outer queries. However for
some reason I wasn't getting the behaviour I was expecting and subqueries
didn't seem to have them in scope.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2007-02-21 20:57:03 bug in CHECK(some SIMILAR TO ..)
Previous Message Andrew Dunstan 2007-02-21 20:55:31 Re: Column storage positions