Re: pg_dump assertion failure with "-n pg_catalog"
От | Peter Eisentraut |
---|---|
Тема | Re: pg_dump assertion failure with "-n pg_catalog" |
Дата | |
Msg-id | be43b547-3e28-769f-47d8-5b44f95facae@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"
|
Список | 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.
В списке pgsql-bugs по дате отправления: