Re: Command order bug in pg_dump

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> Maybe we can change the naming policy so that these internal constraint
> objects have names that are unlikely to be chosen by users, maybe by
> suffixing "fkey_int" instead of "fkey", or something like that. (We
> could even do "$1" and so on for this kind of constraint). In
> hindsight, it isn't such a great idea to let the system choose the best
> name for an internal implementation object.

I experimented with the attached, which approximates "add some digits
to the name used for the parent constraint". (We could refactor
ChooseConstraintName if we wanted a less approximate version of that
rule, but I'm not sure it's worth the trouble.)

The extent to which these derived names leak out to the user, as
illustrated by the regression test changes, makes me even less happy
about the fact that \d doesn't show them. I think we really ought
to try to find a way to not need these entries. But that is clearly
not v18 material at this point.

> I'd probably not change this in versions 13 and 14 at all in any case,
> because the code is too different. I'm unsure whether this is enough of
> a bug to consider backpatching to 15-17; maybe we should just change 18
> at this point, since I haven't heard of a user complaining about this.

Kirill's complaint isn't that? But I agree that changing this rule in
stable branches would probably be a net negative user experience,
seeing that the names are plenty user-visible.

regards, tom lane