Re: pgsql: Fix pg_restore's direct-to-database mode for standard_conforming
От | Thom Brown |
---|---|
Тема | Re: pgsql: Fix pg_restore's direct-to-database mode for standard_conforming |
Дата | |
Msg-id | CAA-aLv63eWyN6jCE6C-G43_dnXqKyPUPOPnKXwCbg5U2tgXYsw@mail.gmail.com обсуждение исходный текст |
Ответ на | pgsql: Fix pg_restore's direct-to-database mode for standard_conforming (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Fix pg_restore's direct-to-database mode for standard_conforming
|
Список | pgsql-committers |
On 28 July 2011 19:08, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Fix pg_restore's direct-to-database mode for standard_conforming_strings. > > pg_backup_db.c contained a mini SQL lexer with which it tried to identify > boundaries between SQL commands, but that code was not designed to cope > with standard_conforming_strings, and would get the wrong answer if a > backslash immediately precedes a closing single quote in such a string, > as per report from Julian Mehnle. The bug only affects direct-to-database > restores from archive files made with standard_conforming_strings = on. > > Rather than complicating the code some more to try to fix that, let's just > rip it all out. The only reason it was needed was to cope with COPY data > embedded into ordinary archive entries, which was a layout that was used > only for about the first three weeks of the archive format's existence, > and never in any production release of pg_dump. Instead, just rely on the > archive file layout to tell us whether we're printing COPY data or not. > > This bug represents a data corruption hazard in all releases in which > standard_conforming_strings can be turned on, ie 8.2 and later, so > back-patch to all supported branches. So presumably this doesn't need to be on the Open Items list as a beta blocker? -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-committers по дате отправления: