Re: Incremental results from libpq

Tom,

True in it's entirety, and as I posted recently I don't believe
the differences amount to a hill of beans. Take a tack & stick with it.
If this is the direction the PostGreSql development team want to follow,
then so be it. At least the temp table concept exists. And yes it does
exist in the 8.1 docs, just found it. Thanks.

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Wednesday, November 16, 2005 8:04 PM
To: Alvaro Herrera
Cc: Bruce Momjian; Goulet, Dick; Peter Eisentraut;
pgsql-interfaces(at)postgresql(dot)org; Scott Lamb
Subject: Re: [INTERFACES] Incremental results from libpq

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Bruce Momjian wrote:
>> How is it better than what we have now?

> Global temporary tables are defined only once (not once per session),
> and the schema (definition) is known to all sessions. Only the
content
> is private to each session.

Basically, this trades off ease of initialization (you don't have to
create the table in each session, 'cause it's already there) for
flexibility (all sessions have to use the same definition of the same
temp table name).

Note that it's *not* global vs local temp tables; that distinction, in
the spec, has to do with visibility across module boundaries, an issue
that we do not have because we do not have modules. In the spec, all
temp tables act this way, and there's actually no way to produce the
effect we have of fully session-local temp tables. I don't think we
want to buy into the spec definition completely.

Still, I can think of lots of applications where all users of the
database are running basically the same code and so there's no real need
for session-private temp table schemas. In that scenario it's
definitely simpler if functions don't have to worry about creating a
temp table before they can use it.

regards, tom lane