Re: Re: Small bug in pg_dump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: Small bug in pg_dump
Date
Msg-id 11503.984615043@sss.pgh.pa.us
Whole thread Raw
In response to Re: Small bug in pg_dump  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: Re: Small bug in pg_dump  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
Philip Warner <pjw@rhyme.com.au> writes:
> Fixed & done...

Only part of the way there: pg_dump is still pretty seriously broken for
mixed-case table names.  Observe:

regression=# create table "Foo" (z int);
CREATE
regression=# \q
$ pg_dump -a -t '"Foo"' regression
--
-- Selected TOC Entries:
--
--
-- Data for TOC Entry ID 1 (OID 1845087) TABLE DATA "Foo"
--

\connect - postgres
-- Disable triggers
UPDATE "pg_class" SET "reltriggers" = 0 WHERE "relname" = '"Foo"';

COPY "Foo"  FROM stdin;
\.
-- Enable triggers
UPDATE pg_class SET reltriggers = (SELECT count(*) FROM pg_trigger where pg_class.oid = tgrelid) WHERE relname =
'"Foo"';

$

These UPDATEs will certainly not work.  On digging into the code, the
problem seems to be one of premature optimization: fmtId() is applied
to the table name when the ArchiveEntry is created, rather than when
printing out from an ArchiveEntry.  So there is no way to get the
undecorated table name for use in these commands.

It seems to me that you should remove the fmtId() from calls to
ArchiveEntry.  Then add it back where an archive entry's name is
being printed (and quoting is appropriate).  It might even make
sense for an ArchiveEntry to store both forms of the name, and then
using code could just select the form wanted instead of calling
fmtId repeatedly.  Not sure.

BTW, making the -t switch compare to the unquoted name would probably
also fix the bizarre need for '"Foo"' exhibited above.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Kaare Rasmussen
Date:
Subject: Re: Re: Week number
Next
From: "G. Anthony Reina"
Date:
Subject: rtrim giving weird result