Re: Foreign keys for non-default datatypes, redux - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Foreign keys for non-default datatypes, redux
Date
Msg-id 22787.1171258594@sss.pgh.pa.us
Whole thread Raw
In response to Re: Foreign keys for non-default datatypes, redux  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Responses Re: Foreign keys for non-default datatypes, redux  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
List 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: select from sequences
Next
From: Tom Lane
Date:
Subject: Re: HOT for PostgreSQL 8.3