To: Alvaro Herrera <alvherre@commandprompt.com>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, "Goulet, Dick" <DGoulet@vicr.com>,
	Peter Eisentraut <peter_e@gmx.net>, pgsql-interfaces@postgresql.org,
	Scott Lamb <slamb@slamb.org>
Subject: Re: Incremental results from libpq 
In-reply-to: <20051117005043.GD24640@surnet.cl> 
References: 
 <4001DEAF7DF9BD498B58B45051FBEA6502EF55DA@25exch1.vicorpower.vicr.com>
	<200511162013.jAGKDHY22079@candle.pha.pa.us>
	<20051117005043.GD24640@surnet.cl>
Comments: In-reply-to Alvaro Herrera <alvherre@commandprompt.com>
	message dated "Wed, 16 Nov 2005 21:50:43 -0300"
Date: Wed, 16 Nov 2005 20:04:23 -0500
Message-ID: <20610.1132189463@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Alvaro Herrera <alvherre@commandprompt.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