Re: Re: [GENERAL] pg_dump behaves differently for different archive formats

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: [GENERAL] pg_dump behaves differently for different archive formats
Дата
Msg-id 32504.1406555764@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] pg_dump behaves differently for different archive formats  (Albe Laurenz <laurenz.albe@wien.gv.at>)
Ответы Re: Re: [GENERAL] pg_dump behaves differently for different archive formats  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
Albe Laurenz <laurenz.albe@wien.gv.at> writes:
> I thought that changing the dump format for this would be too
> much trouble, so I came up with the attached.

> It assumes that custom- or tar-format archives are written by pg_dump
> and cannot contain arbitrary SQL statements, which allows me to get away
> with very simple parsing.

I don't think this can be trusted in the least.  To begin with, where'd
you get the idea dumps cannot contain "arbitrary SQL statements"?  CREATE
RULE at least could contain some pretty weird stuff.  This thing doesn't
look like it's even bothering to count nested parentheses, so it will
certainly fail on a multi-statement rule.  I believe you're also at risk
of SQL injection attacks from failing to account for multibyte characters
in non-ASCII-safe client encodings.

While those specific problems could no doubt be fixed, I object to the
entire concept of assuming that what pg_dump emits is always going to be
trivially parsable.  If we are to go down this path, I think we have to
replicate what psql is doing to identify statement boundaries ... and
as I mentioned upthread, that's rather a lot of code :-(
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Albe Laurenz
Дата:
Сообщение: Re: [GENERAL] pg_dump behaves differently for different archive formats
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: building pdfs