pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18923: pg_dump 18beta1 fails to process complex table names
10+ messages / 6 participants
[nested] [flat]
* BUG #18923: pg_dump 18beta1 fails to process complex table names
@ 2025-05-12 06:57 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 10+ messages in thread
From: PG Bug reporting form @ 2025-05-12 06:57 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: phb.emaj@free.fr
The following bug has been logged on the website:
Bug reference: 18923
Logged by: Philippe BEAUDOIN
Email address: phb.emaj@free.fr
PostgreSQL version: 18beta1
Operating system: Linux
Description:
I have just run the E-Maj project regression test suite with PG18 beta1 and
found a pg_dump abort when trying to dump a schema prefixed table having a
complex name including single quote, double quote and space.
Here is a test case to reproduce it :
#!/bin/sh
PG18_BIN=/home/postgres/pg/pg18/bin
PG18_PORT=5418
echo "------ Setup a new database with a single schema and table"
$PG18_BIN/dropdb -h localhost -p $PG18_PORT --if-exists bug
$PG18_BIN/createdb -h localhost -p $PG18_PORT bug
$PG18_BIN/psql -h localhost -p $PG18_PORT bug <<EOF
select version();
SET client_min_messages TO WARNING;
CREATE SCHEMA "phil's schema""3";
SET search_path="phil's schema""3";
DROP TABLE IF EXISTS "phil's tbl1";
CREATE TABLE "phil's tbl1" (
"phil's col11" INT NOT NULL PRIMARY KEY,
"phil's col12" TEXT
);
EOF
echo "------ Dump the database"
$PG18_BIN/pg_dump --version
$PG18_BIN/pg_dump -h localhost -p $PG18_PORT --verbose bug >/dev/null
And here is what I get :
------ Setup a new database with a single schema and table
version
----------------------------------------------------------------------------------------------------------
PostgreSQL 18beta1 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
13.3.0-6ubuntu2~24.04) 13.3.0, 64-bit
(1 row)
SET
CREATE SCHEMA
SET
DROP TABLE
CREATE TABLE
------ Dump the database
pg_dump (PostgreSQL) 18beta1
pg_dump: executing SELECT pg_catalog.set_config('search_path', '', false);
pg_dump: last built-in OID is 16383
pg_dump: reading extensions
pg_dump: identifying extension members
pg_dump: reading schemas
pg_dump: reading user-defined tables
pg_dump: reading user-defined functions
pg_dump: reading user-defined types
pg_dump: reading procedural languages
pg_dump: reading user-defined aggregate functions
pg_dump: reading user-defined operators
pg_dump: reading user-defined access methods
pg_dump: reading user-defined operator classes
pg_dump: reading user-defined operator families
pg_dump: reading user-defined text search parsers
pg_dump: reading user-defined text search templates
pg_dump: reading user-defined text search dictionaries
pg_dump: reading user-defined text search configurations
pg_dump: reading user-defined foreign-data wrappers
pg_dump: reading user-defined foreign servers
pg_dump: reading default privileges
pg_dump: reading user-defined collations
pg_dump: reading user-defined conversions
pg_dump: reading type casts
pg_dump: reading transforms
pg_dump: reading table inheritance information
pg_dump: reading event triggers
pg_dump: finding extension tables
pg_dump: finding inheritance relationships
pg_dump: reading column info for interesting tables
pg_dump: flagging inherited columns in subtables
pg_dump: reading partitioning data
pg_dump: reading indexes
pg_dump: flagging indexes in partitioned tables
pg_dump: reading extended statistics
pg_dump: reading constraints
pg_dump: reading triggers
pg_dump: reading rewrite rules
pg_dump: reading policies
pg_dump: reading row-level security policies
pg_dump: reading publications
pg_dump: reading publication membership of tables
pg_dump: reading publication membership of schemas
pg_dump: reading subscriptions
pg_dump: reading subscription membership of tables
pg_dump: reading large objects
pg_dump: reading dependency data
pg_dump: saving encoding = UTF8
pg_dump: saving "standard_conforming_strings = on"
pg_dump: saving "search_path = "
pg_dump: creating SCHEMA "phil's schema"3"
pg_dump: creating TABLE "phil's schema"3.phil's tbl1"
pg_dump: processing data for table "phil's schema"3.phil's tbl1"
pg_dump: dumping contents of table "phil's schema"3.phil's tbl1"
pg_dump: error: query failed: ERROR: syntax error at or near "s"
LINE 1: EXECUTE getAttributeStats('{"phil's schema""3","phil's schem...
^
pg_dump: detail: Query was: EXECUTE getAttributeStats('{"phil's
schema""3","phil's schema""3"}'::pg_catalog.name[],'{"phil's tbl1","phil's
tbl1_pkey"}'::pg_catalog.name[])
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18923: pg_dump 18beta1 fails to process complex table names
@ 2025-05-12 13:51 Tom Lane <tgl@sss.pgh.pa.us>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 10+ messages in thread
From: Tom Lane @ 2025-05-12 13:51 UTC (permalink / raw)
To: phb.emaj@free.fr; +Cc: pgsql-bugs@lists.postgresql.org
PG Bug reporting form <noreply@postgresql.org> writes:
> I have just run the E-Maj project regression test suite with PG18 beta1 and
> found a pg_dump abort when trying to dump a schema prefixed table having a
> complex name including single quote, double quote and space.
Thanks for the report! Looks like fetchAttributeStats() is completely
misguided about the appropriate quoting rules for array elements.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18923: pg_dump 18beta1 fails to process complex table names
@ 2025-05-13 11:34 jian he <jian.universality@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: jian he @ 2025-05-13 11:34 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: phb.emaj@free.fr; pgsql-bugs@lists.postgresql.org
On Mon, May 12, 2025 at 9:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> PG Bug reporting form <noreply@postgresql.org> writes:
> > I have just run the E-Maj project regression test suite with PG18 beta1 and
> > found a pg_dump abort when trying to dump a schema prefixed table having a
> > complex name including single quote, double quote and space.
>
> Thanks for the report! Looks like fetchAttributeStats() is completely
> misguided about the appropriate quoting rules for array elements.
>
re-read ReadArrayToken.
In this context, we need to care about single-quote, double-quotes.
for backslash, we skip it.
appendPGArray can help us handle double quotes,
now we just need to make it also handle single quotes.
Attachments:
[text/x-patch] v1-0001-ensure-fetchAttributeStats-subroutine-handle-single-quote.patch (2.6K, ../../CACJufxFLUsXw2tsTLLvWSeO0cX=Wp+fnL-vKK7eiVu0=GSSnRA@mail.gmail.com/2-v1-0001-ensure-fetchAttributeStats-subroutine-handle-single-quote.patch)
download | inline diff:
From 5f79c94fb659f47c7c88d5e9779b6523f211d830 Mon Sep 17 00:00:00 2001
From: jian he <jian.universality@gmail.com>
Date: Tue, 13 May 2025 19:29:34 +0800
Subject: [PATCH v1 1/1] ensure fetchAttributeStats subroutine handle single
quote properly
---
src/bin/pg_dump/pg_dump.c | 16 ++++++++++------
src/fe_utils/string_utils.c | 15 ++++++++++++++-
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index e2e7975b34e..446d7856f29 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -10738,6 +10738,9 @@ fetchAttributeStats(Archive *fout)
static bool restarted;
int max_rels = MAX_ATTR_STATS_RELS;
+ appendPQExpBufferChar(nspnames, '{');
+ appendPQExpBufferChar(relnames, '{');
+
/*
* Our query for retrieving statistics for multiple relations uses WITH
* ORDINALITY and multi-argument UNNEST(), both of which were introduced
@@ -10776,10 +10779,8 @@ fetchAttributeStats(Archive *fout)
if ((te->reqs & REQ_STATS) != 0 &&
strcmp(te->desc, "STATISTICS DATA") == 0)
{
- appendPQExpBuffer(nspnames, "%s%s", count ? "," : "",
- fmtId(te->namespace));
- appendPQExpBuffer(relnames, "%s%s", count ? "," : "",
- fmtId(te->tag));
+ appendPGArray(nspnames, fmtId(te->namespace));
+ appendPGArray(relnames, fmtId(te->tag));
count++;
}
}
@@ -10789,9 +10790,12 @@ fetchAttributeStats(Archive *fout)
{
PQExpBuffer query = createPQExpBuffer();
+ appendPQExpBufferChar(nspnames, '}');
+ appendPQExpBufferChar(relnames, '}');
+
appendPQExpBuffer(query, "EXECUTE getAttributeStats("
- "'{%s}'::pg_catalog.name[],"
- "'{%s}'::pg_catalog.name[])",
+ "'%s'::pg_catalog.name[],"
+ "'%s'::pg_catalog.name[])",
nspnames->data, relnames->data);
res = ExecuteSqlQuery(fout, query->data, PGRES_TUPLES_OK);
destroyPQExpBuffer(query);
diff --git a/src/fe_utils/string_utils.c b/src/fe_utils/string_utils.c
index 130d1020d50..fa63b8c88e1 100644
--- a/src/fe_utils/string_utils.c
+++ b/src/fe_utils/string_utils.c
@@ -942,12 +942,25 @@ appendPGArray(PQExpBuffer buffer, const char *value)
if (ch == '"' || ch == '\\')
appendPQExpBufferChar(buffer, '\\');
+
+ if (ch == '\'')
+ appendPQExpBufferChar(buffer, '\'');
+
appendPQExpBufferChar(buffer, ch);
}
appendPQExpBufferChar(buffer, '"');
}
else
- appendPQExpBufferStr(buffer, value);
+ {
+ for (tmp = value; *tmp; tmp++)
+ {
+ char ch = *tmp;
+
+ if (ch == '\'')
+ appendPQExpBufferChar(buffer, '\'');
+ appendPQExpBufferChar(buffer, ch);
+ }
+ }
}
--
2.34.1
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18923: pg_dump 18beta1 fails to process complex table names
@ 2025-05-15 18:12 Nathan Bossart <nathandbossart@gmail.com>
parent: jian he <jian.universality@gmail.com>
0 siblings, 2 replies; 10+ messages in thread
From: Nathan Bossart @ 2025-05-15 18:12 UTC (permalink / raw)
To: jian he <jian.universality@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; phb.emaj@free.fr; pgsql-bugs@lists.postgresql.org
On Tue, May 13, 2025 at 07:34:51PM +0800, jian he wrote:
> On Mon, May 12, 2025 at 9:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> PG Bug reporting form <noreply@postgresql.org> writes:
>> > I have just run the E-Maj project regression test suite with PG18 beta1 and
>> > found a pg_dump abort when trying to dump a schema prefixed table having a
>> > complex name including single quote, double quote and space.
>>
>> Thanks for the report! Looks like fetchAttributeStats() is completely
>> misguided about the appropriate quoting rules for array elements.
D'oh, my bad.
> re-read ReadArrayToken.
> In this context, we need to care about single-quote, double-quotes.
> for backslash, we skip it.
>
> appendPGArray can help us handle double quotes,
> now we just need to make it also handle single quotes.
I don't think we want to teach appendPGArray() to handle single quotes.
That's meant for building a text representation of a 1-dimensional Postgres
array, which IIUC doesn't need to escape single quotes. Take the following
example:
postgres=# select array['nathan''s element'];
array
----------------------
{"nathan's element"}
(1 row)
My first instinct is that we need to build the array with appendPGArray()
and then append it to the query using appendStringLiteralAH(), as done in
the attached patch.
--
nathan
Attachments:
[text/plain] v2-0001-pg_dump-fix-quoting-in-fetchAttributeStats.patch (0B, ../../aCYumTym-wLvDFp8@nathan/2-v2-0001-pg_dump-fix-quoting-in-fetchAttributeStats.patch)
download
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18923: pg_dump 18beta1 fails to process complex table names
@ 2025-05-15 19:03 Corey Huinker <corey.huinker@gmail.com>
parent: Nathan Bossart <nathandbossart@gmail.com>
1 sibling, 0 replies; 10+ messages in thread
From: Corey Huinker @ 2025-05-15 19:03 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: jian he <jian.universality@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; phb.emaj@free.fr; pgsql-bugs@lists.postgresql.org
>
>
> My first instinct is that we need to build the array with appendPGArray()
> and then append it to the query using appendStringLiteralAH(), as done in
> the attached patch.
>
This patch looks good to me, though I'm wondering if we should add a test
case.
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18923: pg_dump 18beta1 fails to process complex table names
@ 2025-05-15 19:03 Tom Lane <tgl@sss.pgh.pa.us>
parent: Nathan Bossart <nathandbossart@gmail.com>
1 sibling, 1 reply; 10+ messages in thread
From: Tom Lane @ 2025-05-15 19:03 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: jian he <jian.universality@gmail.com>; phb.emaj@free.fr; pgsql-bugs@lists.postgresql.org
Nathan Bossart <nathandbossart@gmail.com> writes:
> I don't think we want to teach appendPGArray() to handle single quotes.
No, that seems quite wrong. array_in won't de-dup single quotes.
> My first instinct is that we need to build the array with appendPGArray()
> and then append it to the query using appendStringLiteralAH(), as done in
> the attached patch.
Yeah, I think so. I was confused for a bit because the one extant
user of appendPGArray is getNamespaces which does an additional layer
of quote-doubling via quoteAclUserName. However, that seems to be because
it's trying to build aclitem[] arrays whose elements will be read by
aclitemin, and that de-dups double quotes.
Wouldn't be a bad idea to add a test case.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18923: pg_dump 18beta1 fails to process complex table names
@ 2025-05-16 14:50 jian he <jian.universality@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: jian he @ 2025-05-16 14:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; phb.emaj@free.fr; pgsql-bugs@lists.postgresql.org
On Fri, May 16, 2025 at 3:03 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Yeah, I think so. I was confused for a bit because the one extant
> user of appendPGArray is getNamespaces which does an additional layer
> of quote-doubling via quoteAclUserName. However, that seems to be because
> it's trying to build aclitem[] arrays whose elements will be read by
> aclitemin, and that de-dups double quotes.
>
getNamespaces use appendPGArray for object's initial ACL string
getNamespaces
``
nsinfo[i].dacl.initprivs = pstrdup(aclarray->data);
``
and we seems *only* use it dumpACL->buildACLCommands
``
if (!parsePGArray(baseacls, &baseitems, &nbaseitems))
{
free(aclitems);
free(baseitems);
return false;
}
``
parsePGArray didn't handle single-quotes.
I think the above is the reason single-quotes within array elements didn't cause
trouble.
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18923: pg_dump 18beta1 fails to process complex table names
@ 2025-05-19 07:24 Stepan Neretin <slpmcf@gmail.com>
parent: jian he <jian.universality@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Stepan Neretin @ 2025-05-19 07:24 UTC (permalink / raw)
To: jian he <jian.universality@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Nathan Bossart <nathandbossart@gmail.com>; phb.emaj@free.fr; pgsql-bugs@lists.postgresql.org
On Fri, May 16, 2025 at 9:51 PM jian he <jian.universality@gmail.com> wrote:
> On Fri, May 16, 2025 at 3:03 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > Yeah, I think so. I was confused for a bit because the one extant
> > user of appendPGArray is getNamespaces which does an additional layer
> > of quote-doubling via quoteAclUserName. However, that seems to be
> because
> > it's trying to build aclitem[] arrays whose elements will be read by
> > aclitemin, and that de-dups double quotes.
> >
>
> getNamespaces use appendPGArray for object's initial ACL string
>
> getNamespaces
> ``
> nsinfo[i].dacl.initprivs = pstrdup(aclarray->data);
> ``
>
> and we seems *only* use it dumpACL->buildACLCommands
> ``
> if (!parsePGArray(baseacls, &baseitems, &nbaseitems))
> {
> free(aclitems);
> free(baseitems);
> return false;
> }
> ``
> parsePGArray didn't handle single-quotes.
>
> I think the above is the reason single-quotes within array elements didn't
> cause
> trouble.
>
>
>
Hi,
I’ve added a regression test covering problem
This patch combines Nathan Bossart’s original fix with suggestions from Tom
Lane and Jian He. It uses appendPGArray() to build the arrays and
appendStringLiteralAH() to quote them correctly in the EXECUTE statement.
Patch attached. Looking forward to your feedback.
Best regards,
Stepan Neretin
Attachments:
[text/x-patch] v2-0001-Fix-quoting-of-complex-schema-and-table-names-in-.patch (3.9K, ../../CA+Yyo5RP7QvPOOgSS0U234HCSA5T-UStin0wkRo1Z_XY5+=VNg@mail.gmail.com/3-v2-0001-Fix-quoting-of-complex-schema-and-table-names-in-.patch)
download | inline diff:
From c29e9e6322368ece386b4e61ad8609fccf0255f7 Mon Sep 17 00:00:00 2001
From: Stepan Neretin <slpmcf@gmail.com>
Date: Mon, 19 May 2025 14:21:39 +0700
Subject: [PATCH v2] Fix quoting of complex schema and table names in
fetchAttributeStats()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The function fetchAttributeStats() incorrectly assumed that array string
literals for EXECUTE getAttributeStats(...) could be safely constructed
using fmtId(), which doesn't escape single quotes. This led to a syntax
error when dumping tables with names containing single quotes, double quotes,
or spaces — as reported in bug #18923.
This patch replaces direct fmtId() appends with appendPGArray(), which correctly
formats array elements, and then quotes the full array string using
appendStringLiteralAH().
Also adds a regression test with a schema and table using complex identifiers,
including embedded single and double quotes, to ensure this scenario is covered.
Patch based on suggestions from Tom Lane, Jian He, and Nathan Bossart.
Author: Nathan Bossart, Stepan Neretin
---
src/bin/pg_dump/pg_dump.c | 21 +++++++++++++--------
src/bin/pg_dump/t/002_pg_dump.pl | 23 +++++++++++++++++++++++
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index e2e7975b34e..06a7684341f 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -10771,28 +10771,33 @@ fetchAttributeStats(Archive *fout)
* This is perhaps not the sturdiest assumption, so we verify it matches
* reality in dumpRelationStats_dumper().
*/
+
+ appendPQExpBufferChar(nspnames, '{');
+ appendPQExpBufferChar(relnames, '{');
for (; te != AH->toc && count < max_rels; te = te->next)
{
if ((te->reqs & REQ_STATS) != 0 &&
strcmp(te->desc, "STATISTICS DATA") == 0)
{
- appendPQExpBuffer(nspnames, "%s%s", count ? "," : "",
- fmtId(te->namespace));
- appendPQExpBuffer(relnames, "%s%s", count ? "," : "",
- fmtId(te->tag));
+ appendPGArray(nspnames, te->namespace);
+ appendPGArray(relnames, te->tag);
count++;
}
}
+ appendPQExpBufferChar(nspnames, '}');
+ appendPQExpBufferChar(relnames, '}');
/* Execute the query for the next batch of relations. */
if (count > 0)
{
PQExpBuffer query = createPQExpBuffer();
- appendPQExpBuffer(query, "EXECUTE getAttributeStats("
- "'{%s}'::pg_catalog.name[],"
- "'{%s}'::pg_catalog.name[])",
- nspnames->data, relnames->data);
+ appendPQExpBufferStr(query, "EXECUTE getAttributeStats(");
+ appendStringLiteralAH(query, nspnames->data, fout);
+ appendPQExpBufferStr(query, "::pg_catalog.name[],");
+ appendStringLiteralAH(query, relnames->data, fout);
+ appendPQExpBufferStr(query, "::pg_catalog.name[])");
+
res = ExecuteSqlQuery(fout, query->data, PGRES_TUPLES_OK);
destroyPQExpBuffer(query);
}
diff --git a/src/bin/pg_dump/t/002_pg_dump.pl b/src/bin/pg_dump/t/002_pg_dump.pl
index 55d892d9c16..29a6d1952bc 100644
--- a/src/bin/pg_dump/t/002_pg_dump.pl
+++ b/src/bin/pg_dump/t/002_pg_dump.pl
@@ -4825,6 +4825,29 @@ my %tests = (
},
},
+
+ 'CREATE SCHEMA "phil\'s schema\"3"' => {
+ create_sql => q{
+ CREATE SCHEMA "phil's schema""3";
+ SET search_path = "phil's schema""3";
+ DROP TABLE IF EXISTS "phil's tbl1";
+ CREATE TABLE "phil's tbl1" (
+ "phil's col11" serial PRIMARY KEY,
+ "phil's col12" text
+ );
+ },
+ regexp => qr/^
+ CREATE\ SCHEMA\ "phil's\ schema""3";\n
+ SET\ search_path\ =\ "phil's\ schema""3";\n
+ DROP\ TABLE\ IF\ EXISTS\ "phil's\ tbl1";\n
+ CREATE\ TABLE\ "phil's\ tbl1"\ \(\n
+ \s+"phil's\ col11"\ integer\ NOT\ NULL\ DEFAULT\ nextval\('[^']+'\)::regclass,\n
+ \s+"phil's\ col12"\ text\n
+ \s+CONSTRAINT\ "[^"]+"\ PRIMARY\ KEY\ \("phil's\ col11"\)\n
+ \);/xm,
+ like => {},
+ },
+
#
# TABLE and MATVIEW stats will end up in SECTION_DATA.
# INDEX stats (expression columns only) will end up in SECTION_POST_DATA.
--
2.43.0
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18923: pg_dump 18beta1 fails to process complex table names
@ 2025-05-19 20:30 Nathan Bossart <nathandbossart@gmail.com>
parent: Stepan Neretin <slpmcf@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Nathan Bossart @ 2025-05-19 20:30 UTC (permalink / raw)
To: Stepan Neretin <slpmcf@gmail.com>; +Cc: jian he <jian.universality@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; phb.emaj@free.fr; pgsql-bugs@lists.postgresql.org
On Mon, May 19, 2025 at 02:24:47PM +0700, Stepan Neretin wrote:
> + 'CREATE SCHEMA "phil\'s schema\"3"' => {
> + create_sql => q{
> + CREATE SCHEMA "phil's schema""3";
> + SET search_path = "phil's schema""3";
> + DROP TABLE IF EXISTS "phil's tbl1";
> + CREATE TABLE "phil's tbl1" (
> + "phil's col11" serial PRIMARY KEY,
> + "phil's col12" text
> + );
> + },
> + regexp => qr/^
> + CREATE\ SCHEMA\ "phil's\ schema""3";\n
> + SET\ search_path\ =\ "phil's\ schema""3";\n
> + DROP\ TABLE\ IF\ EXISTS\ "phil's\ tbl1";\n
> + CREATE\ TABLE\ "phil's\ tbl1"\ \(\n
> + \s+"phil's\ col11"\ integer\ NOT\ NULL\ DEFAULT\ nextval\('[^']+'\)::regclass,\n
> + \s+"phil's\ col12"\ text\n
> + \s+CONSTRAINT\ "[^"]+"\ PRIMARY\ KEY\ \("phil's\ col11"\)\n
> + \);/xm,
> + like => {},
> + },
I don't think this is quite right. IIUC this test runs some commands and
makes sure that a slightly adjusted version of those commands never appears
in the dump output. This is presumably enough to reach the reported
problem, but AFAICT most of the test content is unnecessary. I think we
should simply modify an existing stats test so that we also verify the
dumped stats commands, as done in the attached patch.
--
nathan
Attachments:
[text/plain] v4-0001-pg_dump-fix-quoting-in-fetchAttributeStats.patch (0B, ../../aCuU5dB1DF_jOxfH@nathan/2-v4-0001-pg_dump-fix-quoting-in-fetchAttributeStats.patch)
download
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18923: pg_dump 18beta1 fails to process complex table names
@ 2025-05-20 21:33 Nathan Bossart <nathandbossart@gmail.com>
parent: Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 0 replies; 10+ messages in thread
From: Nathan Bossart @ 2025-05-20 21:33 UTC (permalink / raw)
To: Stepan Neretin <slpmcf@gmail.com>; +Cc: jian he <jian.universality@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; phb.emaj@free.fr; pgsql-bugs@lists.postgresql.org
Committed.
--
nathan
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2025-05-20 21:33 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-05-12 06:57 BUG #18923: pg_dump 18beta1 fails to process complex table names PG Bug reporting form <noreply@postgresql.org>
2025-05-12 13:51 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-05-13 11:34 ` jian he <jian.universality@gmail.com>
2025-05-15 18:12 ` Nathan Bossart <nathandbossart@gmail.com>
2025-05-15 19:03 ` Corey Huinker <corey.huinker@gmail.com>
2025-05-15 19:03 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-05-16 14:50 ` jian he <jian.universality@gmail.com>
2025-05-19 07:24 ` Stepan Neretin <slpmcf@gmail.com>
2025-05-19 20:30 ` Nathan Bossart <nathandbossart@gmail.com>
2025-05-20 21:33 ` Nathan Bossart <nathandbossart@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox