Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 17 Sep 2003, Tom Lane wrote:
>> I think we have two choices: disallow foreign-key references from temp
>> tables to permanent tables, or take out the optimization of storing
>> temp table pages in private memory.
> I think the first is probably b
Tom Lane wrote:
I think we have two choices: disallow foreign-key references from temp
tables to permanent tables, or take out the optimization of storing
temp table pages in private memory. (That would leave the whole "local
buffer manager" module as dead code, I think.) I'm kinda leaning
toward
On Wed, 17 Sep 2003, Tom Lane wrote:
> Kris Jurka <[EMAIL PROTECTED]> writes:
> > ... you are allowed to reference a permanent table from a temp
> > table. The triggers don't work correctly when the table is
> > modified by another backend:
>
> I think we have two choices: disallow foreign-key re
Tom Lane wrote:
> I think we have two choices: disallow foreign-key references from temp
> tables to permanent tables, or take out the optimization of storing
> temp table pages in private memory. (That would leave the whole
"local
> buffer manager" module as dead code, I think.) I'm kinda leanin
Kris Jurka <[EMAIL PROTECTED]> writes:
> ... you are allowed to reference a permanent table from a temp
> table. The triggers don't work correctly when the table is
> modified by another backend:
Hmm, yeah. That worked when we put in the temp-vs-permanent check in
foreign key creation, but it do
On Tue, 16 Sep 2003, Kris Jurka wrote:
> Something else I've noticed about temp tables is that you are
prohibited
> from having a permanent table contain a foreign key reference to a
temp
> table, but you are allowed to reference a permanent table from a temp
> table. The triggers don't work corre
On Tue, 16 Sep 2003, Merlin Moncure wrote:
> I have been playing with temporary tables a little bit and noticed some
> interesting things.
Something else I've noticed about temp tables is that you are prohibited
from having a permanent table contain a foreign key reference to a temp
table, but
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> ... In this case, I think the
> SQL spec was not thought out very well.
Many people think that about a lot of aspects of the spec ;-)
> I did not see a TODO item regarding global temporary tables...has this
> been attempted/done?
We concluded in the
"Tom Lane" writes:
>The SQL spec's notion of temp tables is only tenuously related to ours
>in the first place :-(. However, the spec appears to require that
>references to temp tables be unqualified names, so AFAICT it's not
>expected that applications can reference more than one schema's worth
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> The other and more interesting way is to manually jump into the
> temporary schema (eg. pg_temp_x) that hosts a temp table constructed by
> another backend. While this is unlikely to happen in a normal setting,
> the server does allow it. Following t
Following tests were made in linux server running pg 7.4 beta 2.
I have been playing with temporary tables a little bit and noticed some
interesting things. I'm not sure if this is a part of the standard
canon or not but I thought it worth mentioning. Sorry if I'm bleating
out the obvious!
Acco
11 matches
Mail list logo
