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

Re: Common Table Expressions (WITH RECURSIVE) patch

From: "Greg Stark" <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hitoshi Harada" <umi(dot)tanuki(at)gmail(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-01 14:03:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Oct 1, 2008 at 2:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> So it seems like the appropriate generalization is to have an array of
> read positions inside the tuplestore and allow callers to say "read
> using position N", plus some API to allow positions to be allocated to
> different requestors.  We could get rid of the separate mark pointer by
> implementing an API that allows position X to be copied to position Y.
> But the actual value of a position (a tuple number or file position
> info) would never be exposed to callers.

That's basicaly what had done (though i had n "readers" which
encapsulated the current pointer and mark).

One other reason the tuplestore should know the position of all the
readers is that ideally it would want to be able to discard any tuples
older than the oldest read position. That also means it needs to know
when all the call sites have allocated their position and don't need
to reset it.


In response to


pgsql-hackers by date

Next:From: Brian HurtDate: 2008-10-01 14:05:33
Subject: Re: Block-level CRC checks
Previous:From: Brian HurtDate: 2008-10-01 13:55:55
Subject: Re: Block-level CRC checks

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