From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Foreign keys for non-default datatypes, redux |
Date: | 2007-02-12 05:36:34 |
Message-ID: | 22787.1171258594@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
>> * Add an oid[] column to pg_constraint that stores the equality operator
>> OIDs for a foreign-key constraint, in the same column order as conkey[]
>> and confkey[].
It turns out this isn't sufficient: ri_Check_Pk_Match() wants to
generate PK = PK checks, and the PK = FK operator isn't the right one
for that. The information I suggested adding to pg_constraint isn't
enough to let it find out which operator is the right one.
We could handle this in a couple of ways:
1. Add yet another column with PK=PK operator OIDs to pg_constraint.
2. Add a column with the underlying PK index's OID to pg_constraint, and
expect ri_Check_Pk_Match to dredge the info from that. This is probably
possible, but not exactly trivial because of which-column-is-which
considerations.
3. Leave pg_constraint alone and expect ri_Check_Pk_Match to look in
pg_depend to find out the underlying PK index, then proceed as in #2.
From an efficiency standpoint #1 seems the best, and yet it seems a bit
ugly. Not that the others aren't. Comments, other ideas?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-02-12 05:48:06 | Re: HOT for PostgreSQL 8.3 |
Previous Message | Tom Lane | 2007-02-12 05:22:48 | Re: select from sequences |