On Mon, 21 Apr 2025 at 19:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Doesn't seem to be a new problem, either ... this trace is against
> v13.
Sure, repro was on 12=>13 pg_upgrade.
> We could fool around with the generation rule for the child
constraint's name, but fundamentally we're infringing on user
namespace here, so I think that's likely to just move the problem
cases around.
My view of this problem is that pg_dump fails its purpose (to produce
restorable dump) because... Lack of control? What if we can force
inherited child constraint names?
So, along with AT ADD CONSTRAINT, we can provide a list of names and
say: instead of using a constraint name generation rule, the server
should choose these names in order. I understand this is too much code
for this minor matter, and the fix will be probably just to change
generation rule.
> Why do we need this child pg_constraint entry at all?
Currently no idea.
> In any case, it's pretty awful that we make these entries but
\d does not show them.
Okay... Perhaps, but since the user did not specifically request this,
perhaps we shouldn't display it.
--
Best regards,
Kirill Reshke
