Re: Foreign keys for non-default datatypes, redux
От | Tom Lane |
---|---|
Тема | Re: Foreign keys for non-default datatypes, redux |
Дата | |
Msg-id | 22787.1171258594@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Foreign keys for non-default datatypes, redux (Stephan Szabo <sszabo@megazone.bigpanda.com>) |
Ответы |
Re: Foreign keys for non-default datatypes, redux
|
Список | 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 по дате отправления: