Re: Command order bug in pg_dump

Kirill Reshke <reshkekirill@gmail.com>

From: Kirill Reshke <reshkekirill@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: 2025-04-21T17:30:10Z
Lists: pgsql-bugs
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



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Change the names generated for child foreign key constraints.

  2. doc: Fix memory context level in pg_log_backend_memory_contexts() example.