Re: Re: Small bug in pg_dump
От | Tom Lane |
---|---|
Тема | Re: Re: Small bug in pg_dump |
Дата | |
Msg-id | 11503.984615043@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Small bug in pg_dump (Philip Warner <pjw@rhyme.com.au>) |
Ответы |
Re: Re: Small bug in pg_dump
|
Список | 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 по дате отправления: