Re: pgsql: Fix pg_dump assertion failure when dumping pg_catalog.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Jeff Davis <jdavis(at)postgresql(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Fix pg_dump assertion failure when dumping pg_catalog.
Date: 2023-09-04 13:56:04
Message-ID: 1149326.1693835764@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> I have another question about this patch. The original issue was that
> it would trigger an Assert() inside pg_dump when some columns in
> pg_collation were null that were not expected. This patch now contains
> code like

> 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);

> which would produce pg_dump output like

> CREATE COLLATION ... (provider = libc, lc_collate = , lc_ctype = );

> which is not valid syntax.

How so? appendStringLiteral adds quotes around what it's given,
empty string or no.

The receiving server might or might not like those parameters
semantically, but the syntax should be ok.

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Michael Paquier 2023-09-05 04:58:19 pgsql: Improve description of keys in tsvector
Previous Message Amit Kapila 2023-09-04 13:05:14 Re: pgsql: Allow tailoring of ICU locales with custom rules