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)
