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

Re: Common Table Expressions (WITH RECURSIVE) patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com>
Cc: "Greg Stark" <stark(at)enterprisedb(dot)com>, "Dimitri Fontaine" <dfontaine(at)hi-media(dot)com>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Tatsuo Ishii" <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Common Table Expressions (WITH RECURSIVE) patch
Date: 2008-10-02 04:44:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com> writes:
> 2008/10/2 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Okay, there's a patch in CVS HEAD that works this way.  Let me know if
>> it needs further tweaking for your purposes.

> Hmm, I've looked over the patch. Logically window functions can access
> arbitrary rows that have been stored in a frame. Thus I had thought
> tuplestore should hold all the positions and allow arbitrary random
> access indicated by integer. Maybe those functionalities can be
> abstracted by the window function API itself. For this matter it seems
> that you'd better to look at my future patch.

Well, the problem with defining it as "arbitrary" random access is that
there's no way for the tuplestore to throw away old data.

The scheme that I have in mind here is that you keep (at least) two read
pointers, one that is where you're actually reading the data and one
that is nailing down the oldest point you might need to return to.
This is a generalization of the previous mark/restore logic to allow any
number of pairs of mark and restore points.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2008-10-02 05:14:05
Subject: Re: pgsql: Allow pg_regress to be run outside the build tree.
Previous:From: Andrew DunstanDate: 2008-10-02 01:25:09
Subject: Re: Fwd: Has anyone built pgbash-7.3 against postgreSQL-8.3?

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