Re: Allow foreign keys to reference a superset of unique columns
От | Wolfgang Walther |
---|---|
Тема | Re: Allow foreign keys to reference a superset of unique columns |
Дата | |
Msg-id | 1bbb7103-d41c-899d-fe48-115d08fd6c8c@technowledgy.de обсуждение исходный текст |
Ответ на | Re: Allow foreign keys to reference a superset of unique columns (James Coleman <jtc331@gmail.com>) |
Ответы |
Re: Allow foreign keys to reference a superset of unique columns
Re: Allow foreign keys to reference a superset of unique columns |
Список | pgsql-hackers |
James Coleman: > As I was reading through the email chain I had this thought: could you > get the same benefit (or 90% of it anyway) by instead allowing the > creation of a uniqueness constraint that contains more columns than > the index backing it? So long as the index backing it still guaranteed > the uniqueness on a subset of columns that would seem to be safe. > > Tom notes the additional columns being nullable is something to think > about. But if we go the route of allowing unique constraints with > backing indexes having a subset of columns from the constraint I don't > think the nullability is an issue since it's already the case that a > unique constraint can be declared on columns that are nullable. Indeed > it's also the case that we already support a foreign key constraint > backed by a unique constraint including nullable columns. > > Because such an approach would, I believe, avoid changing the foreign > key code (or semantics) at all, I believe that would address Tom's > concerns about information_schema and fuzziness of semantics. 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. Best Wolfgang
В списке pgsql-hackers по дате отправления: