From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
Subject: | Re: idea: global temp tables |
Date: | 2009-04-29 10:33:33 |
Message-ID: | 200904291333.34205.peter_e@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 | Dimitri Fontaine | 2009-04-29 13:43:44 | Documentation: GiST extension implementation |
Previous Message | Zdenek Kotala | 2009-04-29 09:49:31 | Re: idea: global temp tables |