Re: pg_dump assertion failure with "-n pg_catalog"

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>
To: Peter Eisentraut <peter@eisentraut.org>, Michael Paquier <michael@paquier.xyz>
Cc: pgsql-bugs@postgresql.org
Date: 2023-09-05T22:33:09Z
Lists: pgsql-bugs
On Tue, 2023-09-05 at 11:45 +0200, Peter Eisentraut wrote:
> 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.

It already issues a warning, which seemed more consistent with other
unexpected situations in pg_dump.

> 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.

The backend does not accept a collation specified with lc_ctype and not
lc_collate (or vice versa), so it would be an un-restorable dump. That
doesn't seem great.

Regards,
	Jeff Davis




Commits

  1. Fix pg_dump assertion failure when dumping pg_catalog.