From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: pgsql-bugs@postgresql.org, Alvaro Herrera <alvherre@alvh.no-ip.org>
Subject: Re: Command order bug in pg_dump
Date: Mon, 21 Apr 2025 13:08:05 -0400
Message-ID: <769270.1745255285@sss.pgh.pa.us> (raw)
In-Reply-To: <592472.1745247403@sss.pgh.pa.us>
References: <CALdSSPhGitjpTfzEMJN-Y2x+Q-5QChSxAsmSJ1-E8mQJLkHOqQ@mail.gmail.com>
<592472.1745247403@sss.pgh.pa.us>
I wrote:
> I don't think this is pg_dump's fault: there is no such constraint
> when the ALTER TABLE starts. Something inside the ALTER TABLE
> recursion seems to be messing up if there is already another
> similar FK constraint.
Oh, I see what's happening. We create both the specified constraint
and an inherited child constraint on the named partitioned table.
If tt_a_fkey is added first, the name chosen for its child is
"tt_i_fkey", breaking the later attempt by the user to use that name.
Apparently there is some hack in psql to not show that child
constraint entry, because you don't see it in \d output, which
is what confused me before (and would confuse most people
hitting this).
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. Why do we need this child pg_constraint entry at all?
If we can't avoid having it, probably choosing a name like
"tt_a_fkey1" would be marginally less likely to cause trouble
... but only marginally.
In any case, it's pretty awful that we make these entries but
\d does not show them.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, reshkekirill@gmail.com, alvherre@alvh.no-ip.org
Subject: Re: Command order bug in pg_dump
In-Reply-To: <769270.1745255285@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox