Re: Foreign keys for non-default datatypes, redux

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

In response to

Responses

Browse pgsql-hackers by date

  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