Re: Why does Postgres allow duplicate (FK) constraints
От | Alban Hertroys |
---|---|
Тема | Re: Why does Postgres allow duplicate (FK) constraints |
Дата | |
Msg-id | CAF-3MvN40FiuBMCA5Q4kLYqmnduTbGoHdUKVaJmJqt5JRe-TeQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Why does Postgres allow duplicate (FK) constraints (Thomas Kellerer <spam_eater@gmx.net>) |
Ответы |
Re: Why does Postgres allow duplicate (FK) constraints
|
Список | pgsql-general |
On 26 March 2013 17:07, Thomas Kellerer <spam_eater@gmx.net> wrote:
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.
Is there anything in the standard that actively requires that you can create two "identical" constraints?
Because technically it simply doesn't make sense, does it?
It can make sense during a maintenance window, if you create a new (redundant) FK constraint concurrently to replace the existing one. If you'd first remove the existing constraint, you're allowing FK violations until the new constraint has finished creating its index.
This happens for example if you want to use a different index algorithm, say a gist index instead of a btree index, or if the initial index has gotten corrupt somehow and it needs reindexing.
-- If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.
В списке pgsql-general по дате отправления: