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.
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 |