Re: Command order bug in pg_dump

On 2025-Apr-22, Tom Lane wrote:

> After poking at that, it's easy to get ChooseConstraintName to do
> something just slightly different from what I said above: the rule is
> now "add an underscore and some digits to the name used for the parent
> constraint".  I like this even better than the previous idea, because
> I think it makes it more obvious that the name is derived from the
> parent constraint.  However, this changes the chosen name in more
> cases than my previous hack did.  So I'm reposting the patch to see
> if anyone feels this is too much churn.  I think it's okay as a
> v18-only patch, though I wouldn't propose it for back-patch.

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.

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.

(My position on pg_upgrade is that if pg_upgrade --check passes, then
you shouldn't need any additional tests for assurance that running
pg_upgrade for real is going to work.  So I would be happier if we could
detect this problem.)

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"La primera ley de las demostraciones en vivo es: no trate de usar el sistema.
Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen)