> 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)?

Reply via email to