Re: Command order bug in pg_dump

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@kurilemu.de>
Cc: Kirill Reshke <reshkekirill@gmail.com>, pgsql-bugs@postgresql.org
Date: 2025-04-22T20:53:23Z
Lists: pgsql-bugs

Attachments

I wrote:
> Alvaro Herrera <alvherre@kurilemu.de> writes:
>> On 2025-Apr-21, Tom Lane wrote:
>>> 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.)

>> This seems a better implementation of the idea than what I had in mind.
>> For my part, please feel free to go ahead with this.

> OK.  I'll take a look first at whether the aforesaid refactoring
> is easy enough to be worth doing.

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.

			regards, tom lane

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.