Re: pg_dump assertion failure with "-n pg_catalog"
Peter Eisentraut <peter@eisentraut.org>
From: Peter Eisentraut <peter@eisentraut.org>
To: Jeff Davis <pgsql@j-davis.com>, Michael Paquier <michael@paquier.xyz>
Cc: pgsql-bugs@postgresql.org
Date: 2023-09-05T09:45:33Z
Lists: pgsql-bugs
On 16.06.23 00:47, Jeff Davis wrote:
> else
> {
> appendPQExpBufferStr(q, ", lc_collate = ");
> - appendStringLiteralAH(q, collcollate, fout);
> + appendStringLiteralAH(q, collcollate ? collcollate : "", fout);
> appendPQExpBufferStr(q, ", lc_ctype = ");
> - appendStringLiteralAH(q, collctype, fout);
> + appendStringLiteralAH(q, collctype ? collctype : "", fout);
> }
>
This new code replaces an (unexpected) null value with an empty string.
Is that correct? Empty locale strings have specific behaviors under the
libc and icu providers. It seems to me it would be better to error out
or don't print a CREATE COLLATION command at all rather than
substituting a value that is not a correct substitute.
Alternatively, a more correct way to produce a null value would be to
not issue the assignment at all (omit the " lc_collation = " etc.).
Then we can leave it up to the backend to accept the command or not, but
at least the dump closely reflects the original catalog state.
Commits
-
Fix pg_dump assertion failure when dumping pg_catalog.
- 37188cea0c16 17.0 landed
- 501704e826fc 16.0 landed
- 1d9976d1bd00 15.5 landed