Re: Explicit specification of index ensuring uniqueness of foreign columns
От | Tom Lane |
---|---|
Тема | Re: Explicit specification of index ensuring uniqueness of foreign columns |
Дата | |
Msg-id | 4827.1717181175@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Explicit specification of index ensuring uniqueness of foreign columns (Kaiting Chen <ktchen14@gmail.com>) |
Ответы |
Re: Explicit specification of index ensuring uniqueness of foreign columns
|
Список | pgsql-hackers |
Kaiting Chen <ktchen14@gmail.com> writes: > I'd like to resurrect a subset of my proposal in [1], specifically that: > The FOREIGN KEY constraint syntax gains a [ USING INDEX index_name ] clause > optionally following the referenced column list. > ... > While, in this minimal reproduction, the two indexes are interchangeable, there > are situations that may reasonably occur in the course of ordinary use in which > they aren't. For example, a redundant unique index with different storage > parameters may exist during the migration of an application schema. I agree that there's a hazard there, but I question if the case is sufficiently real-world to justify the costs of introducing a non-SQL-standard clause in foreign key constraints. One such cost is that pg_dump output would become less able to be loaded into other DBMSes, or even into older PG versions. I also wonder if this wouldn't just trade one fragility for another. Specifically, I am not sure that we guarantee that the names of indexes underlying constraints remain the same across dump/reload. If they don't, the USING INDEX clause might fail unnecessarily. As against that, I'm not sure I've ever seen a real-world case with intentionally-duplicate unique indexes. So on the whole I'm unconvinced that this is worth changing. regards, tom lane
В списке pgsql-hackers по дате отправления: