| 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: | Whole Thread | Raw Message | 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 |