Re: Foreign key bugs + other problems - Mailing list pgsql-hackers

From Stephan Szabo
Subject Re: Foreign key bugs + other problems
Date
Msg-id 01f001bfeb78$c1396430$0c64010a@kick.com
Whole thread Raw
In response to Re: Foreign key bugs (Re: [BUGS] "New" bug?? Serious - crashesbackend.)  (JanWieck@t-online.de (Jan Wieck))
Responses Re: Foreign key bugs + other problems  (JanWieck@t-online.de (Jan Wieck))
Re: Foreign key bugs + other problems  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Stephan Szabo wrote:
> >
> > Also, I realized something else that is a little wierd.  When a
temporary
> > table shadows a permanent table that you've made a foreign key reference
> > to, which table should it be going to check the constraint?

>     Outch  -  that hurts. Haven't checked it yet, but from what I
>     have  in  memory  it  should  be  a  possibility  to  violate
>     constraints.

Yeah, I realized it when I was going in on AlterTableAddConstraint that I
need to prevent constraints referencing temporary tables on permanent
tables, and then I realized that the shadowing is a problem.  Also, this is
a problem for other users too, what about people who log things to
other tables via rules and triggers?   At least you can't shadow the
system catalogs :-)

I think that schemas might help, if you assume that at creation time of a
rule or constraint you must qualify any tables being used in a way that
prevents misunderstandings, since temporary tables live in a different
system defined schema assuming that schema.tablename is not
shadowed, only the unadorned tablename. In the FK case, I think
that the idea of moving to keeping oids would probably be the way
to go (that way the table is very explicitly defined as a particular one).
Not that this will help right now since I don't think we can make an
SPI request that will handle it.

Or, you might be able to make a case that you CANNOT shadow a table
that is referenced by a constraint (due to the permanent table constraints
cannot reference a temporary table restriction).  Since the creation of
the temp table would break the restriction, it is illegal.

-----

In an unrelated problem.  Well, I was thinking, well, maybe we could for
this transaction during the execution of the trigger, rename the temp table
and then rename it back.  Noone else should see the change (right?) because
we're not comitted and that user isn't doing anything else while we're
checking.
However, this tickles another problem.  It seems that you can't rename a
temp
table.  In fact it does something bad:

create table z (a int);
create temp table z (a int);
alter table z rename to zz;
select * from z;
ERROR: relation 'z' does not exist
select * from zz;
- 0 rows
\q
<enter again>
select * from z;
NOTICE:  mdopen: couldn't open z: No such file or directory
NOTICE:  RelationIdBuildRelation: smgropen(z): Input/output error
NOTICE:  mdopen: couldn't open z: No such file or directory
NOTICE:  mdopen: couldn't open z: No such file or directory
NOTICE:  mdopen: couldn't open z: No such file or directory
NOTICE:  mdopen: couldn't open z: No such file or directory
ERROR:  cannot open relation z
select * from zz;
- 0 rows






pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCHES] PostgreSQL virtual hosting support
Next
From: "Timothy H. Keitt"
Date:
Subject: system tables