Re: observations about temporary tables and schemas

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Kris Jurka" <books(at)ejurka(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: observations about temporary tables and schemas
Date: 2003-09-17 12:29:56
Message-ID: 303E00EBDD07B943924382E153890E5434A9D5@cuthbert.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, 16 Sep 2003, Kris Jurka wrote:
> Something else I've noticed about temp tables is that you are
> from having a permanent table contain a foreign key reference to a
> table, but 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 had no idea this was even possible. IHRTS (I haven't read the spec),
but again here temp tables seem to break rules in strange and unexpected
ways. From the docs, we know that temp tables are 'dropped' after the
connection is broken. With RI in mind, (and more generally, triggers)
the nature and execution of that drop is important.

All that being said, using RI in temp tables (especially with regular
tables) is asking for trouble. The reason I was hoping to keep them in
a special schema is that I use them as a kind of a database enforced
mutex object using the name of the table as the mutex identifier. By
holding them in a special schema (e.g. locks) that is not in the schema
search path I can bypass name resolution problems that happened when the
'mutex' id is the same name as another table (actually, there are no
problems, it simply isn't allowed!).


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-09-17 14:26:32 Re: observations about temporary tables and schemas
Previous Message Tom Lane 2003-09-17 05:21:26 Re: [BUGS] pg_dump/all doesn't output schemas correctly