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 →
-
Change the names generated for child foreign key constraints.
- 3db61db48ef5 18.0 landed
-
doc: Fix memory context level in pg_log_backend_memory_contexts() example.
- 706cbed35103 18.0 cited