Re: pg_dump assertion failure with "-n pg_catalog"
От
Jeff Davis
Тема
Re: pg_dump assertion failure with "-n pg_catalog"
Дата
Msg-id
c1037306f233c7705d00e05239d9c98a6bd62ad7.camel@j-davis.com
Ответ на
Re: pg_dump assertion failure with "-n pg_catalog" (Peter Eisentraut)
Список
Дерево обсуждения
pg_dump assertion failure with "-n pg_catalog" Jeff Davis <pgsql@j-davis.com>
Re: pg_dump assertion failure with "-n pg_catalog" Michael Paquier <michael@paquier.xyz>
Re: pg_dump assertion failure with "-n pg_catalog" Jeff Davis <pgsql@j-davis.com>
Re: pg_dump assertion failure with "-n pg_catalog" Peter Eisentraut <peter@eisentraut.org>
Re: pg_dump assertion failure with "-n pg_catalog" Jeff Davis <pgsql@j-davis.com>
Re: pg_dump assertion failure with "-n pg_catalog" Michael Paquier <michael@paquier.xyz>
Re: pg_dump assertion failure with "-n pg_catalog" Jeff Davis <pgsql@j-davis.com>
Re: pg_dump assertion failure with "-n pg_catalog" Jeff Davis <pgsql@j-davis.com>
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
В списке pgsql-bugs по дате отправления
От: PG Bug reporting form
Дата:
От: Lepikhov Andrei
Дата: