Rod Taylor <rbt@rbt.ca> writes:
> I do agree that a dependency entry from the foreign key constraint to
> the unique or primary key constraint would be useful. That information
> isn't immediately available, as the initial check is performed early on
> in the parser. The constraint creation code makes the assumption that
> one already exists.
I have restructured the parsing and execution code for ADD FOREIGN KEY
so that this information is more readily available. CVS tip will now
create a dependency from the pg_constraint entry for the FK constraint
to the unique index that was found to match the referenced columns.
(Should there be more than one such unique index, I believe you'll get
the one of smallest OID.)
>> On a somewhat related note...
>>
>> CREATE UNIQUE INDEX does not add an entry to pg_constraint.
> The reason that this wasn't done, is that it changes the properties of
> old style unique constraints. You'll notice we also left old style
> foreign keys, and serial columns alone as well.
Right, this was a deliberate omission.
> I'm hoping to depreciate this method of creating a unique index, but it
> will take a number of releases before it can be done.
I don't think so; unique partial indexes, unique functional indexes,
and unique indexes with non-btree access methods are all potentially
useful, but are unsupported by the standard UNIQUE-constraint syntax.
I don't see any value in trying to munge the constraint syntax to
support these things, when the CREATE INDEX command is already there
and perfectly satisfactory.
regards, tom lane