From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Eckermann <jeff_eckermann(at)yahoo(dot)com> |
Cc: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: UNIQUE constraint matching given keys for referenced |
Date: | 2002-08-09 14:07:27 |
Message-ID: | 578.1028902047@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jeff Eckermann <jeff_eckermann(at)yahoo(dot)com> writes:
> Seems kind of odd that PostgreSQL should care more
> about the non-existence of the unique constraint on a
> field than about the non-existence of that field
> itself.
Yeah, that's irritated me too. It doesn't look quite trivial to fix
though, since you can't just check that the fields exist --- they may
not exist, yet. Consider a self-referential table:
create table tree_nodes (id int primary key,
parent int references tree_nodes(id),
...);
There are double code paths in all of the analyze.c code for foreign
keys to handle both the already-exists and the will-create-it case.
Rearranging things to check column existence before existence of the
constraint thus looks a bit tricky.
But feel free to send in a patch ;-)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | am | 2002-08-09 14:35:00 | handling transactions from C (libpq) |
Previous Message | Tom Lane | 2002-08-09 13:41:16 | Re: The standard 'why does it take so long' question |