Message-ID: <c1037306f233c7705d00e05239d9c98a6bd62ad7.camel@j-davis.com>
Subject: Re: pg_dump assertion failure with "-n pg_catalog"
From: Jeff Davis <pgsql@j-davis.com>
To: Peter Eisentraut <peter@eisentraut.org>, Michael Paquier
	 <michael@paquier.xyz>
Cc: pgsql-bugs@postgresql.org
Date: Tue, 05 Sep 2023 15:33:09 -0700
In-Reply-To: <be43b547-3e28-769f-47d8-5b44f95facae@eisentraut.org>
References: <ce071503fee88334aa70f360e6e4ea14d48305ee.camel@j-davis.com>
	 <ZIbAuHfnWY05VxVt@paquier.xyz>
	 <e7c1adfe66542eca348de7485990abfabdbc1086.camel@j-davis.com>
	 <be43b547-3e28-769f-47d8-5b44f95facae@eisentraut.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/c1037306f233c7705d00e05239d9c98a6bd62ad7.camel%40j-davis.com>
Precedence: bulk

On Tue, 2023-09-05 at 11:45 +0200, Peter Eisentraut wrote:
> This new code replaces an (unexpected) null value with an empty
> string.=20
> Is that correct?=C2=A0 Empty locale strings have specific behaviors under
> the=20
> libc and icu providers.=C2=A0 It seems to me it would be better to error
> out=20
> or don't print a CREATE COLLATION command at all rather than=20
> 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 =3D " etc.).=20
> Then we can leave it up to the backend to accept the command or not,
> but=20
> 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