Andrew Dunstan <and...@dunslane.net> writes: > On 03/30/2016 10:21 AM, Tom Lane wrote: >> I think that if we want to ensure uniqueness of constraint names, this >> is really approaching it the wrong way, as it still fails to provide >> any guarantees (consider concurrent index creation, for example). >> What we need is a unique index on pg_constraint.
> +1, but does that mean people will have to change constraint names to be > compliant before running pg_upgrade? Yeah, but I think the situation is pretty uncommon, because we already reject duplicate constraint names in most cases. As far as I could see in testing it earlier, these cases all fail already: * create index constraint when same-named index constraint exists already * create FK constraint when same-named index constraint exists already * create FK constraint when same-named FK constraint exists already * create check constraint when same-named check constraint exists already * create FK constraint when same-named check constraint exists already I think that the case Amit's patch plugged, namely create index constraint when same-named FK or check constraint exists already, may be about the only missing check. I just want a unique index to be sure we are covering all cases. Note also that because pg_dump prefers to create indexes before FK constraints (for obvious reasons), I believe that such a case would fail to dump/restore or pg_upgrade already. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers