From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@kurilemu.de>
cc: Kirill Reshke <reshkekirill@gmail.com>, pgsql-bugs@postgresql.org
Subject: Re: Command order bug in pg_dump
In-reply-to: <202504231301.ln7igwajlzu6@alvherre.pgsql>
References: <202504231301.ln7igwajlzu6@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@kurilemu.de>
	message dated "Wed, 23 Apr 2025 15:01:16 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1344633.1745419300.1@sss.pgh.pa.us>
Date: Wed, 23 Apr 2025 10:41:40 -0400
Message-ID: <1344634.1745419300@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1344634.1745419300%40sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@kurilemu.de> writes:
> I think the new constraint names are better, so +1 for this version of
> the patch for 18.  I agree that we don't necessarily want to backpatch
> this to stable branches though.

Cool, I'll push that patch in a bit then.

> I wonder if it would make pg_upgrade users' lives easier if we had
> pg_upgrade --check notify them about possible collisions on these
> constraints (for the older branches).  I don't have good ideas on how to
> implement that though other than a trial dump/restore, which is perhaps
> unreasonable.

Yeah, I'm not seeing a simple way to do that either.  I'm hesitant to
put a ton of work into it, because in the end the situation seems like
self-inflicted damage.  It's not quite true that you need duplicate
foreign key constraints to hit this, but it's close: the default
table-and-column-name-based name for one constraint has to match the
actual name of a second constraint.  If the second constraint isn't
a duplicate of the first then it has a very misleadingly chosen name.
Either way it's pretty poor DBA practice.

Between that thought and the fact that the problem has gone unnoticed
since v12, I'm content to make this change in the default names and
stop here.

			regards, tom lane