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