Rod Taylor <rbt(at)rbt(dot)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
In response to
pgsql-bugs by date
|Next:||From: fredrik chabot||Date: 2002-09-22 16:26:03|
|Subject: some other backend died abnormally|
|Previous:||From: elein||Date: 2002-09-22 00:35:21|
|Subject: plpython plpy.log/warning minor aesthetic bug|