Re: pg_dump: fix NOT NULL constraint name comparison using makeObjectName

On Thu, Mar 19, 2026 at 2:40 PM JoongHyuk Shin <sjh910805(at)gmail(dot)com> wrote:
> The restore server receives a 64-byte name that exceeds the 63-byte Name
> type limit and silently truncates it to "<55bytes>_not_nul" -- a different
> name from the original "<54bytes>_not_null" that makeObjectName would have
> produced.

I got the reproduction wrong when I wrote the patch.

To decide whether a NOT NULL constraint name stored in pg_constraint is
the automatically generated one, pg_dump compares it with the domain
name followed by _not_null, without any truncation. That decision is
wrong whenever the generated name was truncated to 63 bytes, that is,
when the domain name is longer than 54 bytes.

I assumed that pg_dump then writes the untruncated 64-byte name into the
dump and that the restore server truncates it to a different name, but
pg_dump emits the name stored in pg_constraint, which the server has
already truncated to 63 bytes, so the restored database ends up with the
same constraint name.

So the decision is wrong, but the only consequence is that a name that
could have been left out is written in a CONSTRAINT clause, which is
functionally harmless, and the comment above determineNotNullFlags()
already says as much.

Moving makeObjectName to src/common just for this looks like too much
work, so I have marked the CF entry as Withdrawn. Sorry for the noise.

--
JoongHyuk Shin

>