> Could we create this additional unique constraint implicitly, when using > FOREIGN KEY ... REFERENCES on a superset of unique columns? This would > make it easier to use, but still give proper information_schema output.
Currently, a foreign key declared where the referenced columns have only a unique index and not a unique constraint already populates the constraint related columns of information_schema.referential_constraints with NULL. It doesn't seem like this change would require a major deviation from the existing behavior in information_schema: CREATE TABLE foo (a integer, b integer); CREATE UNIQUE INDEX ON foo (a, b); CREATE TABLE bar ( x integer, y integer, FOREIGN KEY (x, y) REFERENCES foo(a, b) ); # SELECT * FROM information_schema.referential_constraints WHERE constraint_name = 'bar_x_y_fkey'; -[ RECORD 1 ]-------------+---------------------------------------------- constraint_catalog | kaitingc constraint_schema | public constraint_name | bar_x_y_fkey unique_constraint_catalog | unique_constraint_schema | unique_constraint_name | match_option | NONE update_rule | NO ACTION delete_rule | NO ACTION The only change would be to information_schema.key_column_usage: # SELECT * FROM information_schema.key_column_usage WHERE constraint_name = 'bar_x_y_fkey'; -[ RECORD 173 ]---------------+---------------------------------------------- constraint_catalog | kaitingc constraint_schema | public constraint_name | bar_x_y_fkey table_catalog | kaitingc table_schema | public table_name | bar column_name | x ordinal_position | 1 position_in_unique_constraint | 1 -[ RECORD 174 ]---------------+---------------------------------------------- constraint_catalog | kaitingc constraint_schema | public constraint_name | bar_x_y_fkey table_catalog | kaitingc table_schema | public table_name | bar column_name | y ordinal_position | 2 position_in_unique_constraint | 2 Where position_in_unique_constraint would have to be NULL for the referenced columns that don't appear in the unique index. That column is already nullable: For a foreign-key constraint, ordinal position of the referenced column within its unique constraint (count starts at 1); otherwise null So it seems like this would be a minor documentation change at most. Also, should that documentation be updated to mention that it's actually the "ordinal position of the referenced column within its unique index" (since it's a little confusing that in referential_constraints, unique_constraint_name is NULL)?