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

  1. Fix pg_dump assertion failure when dumping pg_catalog.