Re: idea: global temp tables

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: idea: global temp tables
Date: 2009-04-30 12:36:42
Message-ID: 200904301536.42938.peter_e@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The archives for this thread

http://archives.postgresql.org//pgsql-hackers/2009-04/threads.php#01329

show a bunch of missing messages. Were they being stored in a temporary
table?

Anywhere, here is what I had meant to say but only got through to a few ...

On Tuesday 28 April 2009 19:38:25 Tom Lane wrote:
> One thing I just noticed is that the spec does not consider GLOBAL/LOCAL
> to be optional --- per spec you *must* write one or the other in front
> of TEMPORARY. So we could adopt the view that omitting this keyword
> implies our current non-spec behavior (which is far too useful to give
> up, spec compliance or no) while writing one or the other selects the
> spec behavior. However, if we're going to do that then we should start
> throwing warnings for use of the keywords, preferably before the release
> in which they actually start doing something different.

There are actually two orthogonal properties at work here: How the table is
visible with respect to modules (LOCAL/GLOBAL) and whether the table
disappears at the end of the session (currently yes, proposed new behavior
optionally no). We should have two separate settings for these.

On the matter of LOCAL/GLOBAL, I think the correct thing to do is to reject
LOCAL and accept GLOBAL as equivalent to the default.

And then invent a separate setting, say EPHEMERAL/PERSISTENT that controls the
behavior that Pavel requested.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Blewett 2009-04-30 12:44:43 Re: Python 3.0 does not work with PL/Python
Previous Message Peter Eisentraut 2009-04-30 12:18:13 Re: Keyword list sanity check