Re: Re: [GENERAL] pg_dump behaves differently for different archive formats - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [GENERAL] pg_dump behaves differently for different archive formats
Date
Msg-id 32504.1406555764@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] pg_dump behaves differently for different archive formats  (Albe Laurenz <laurenz.albe@wien.gv.at>)
Responses Re: Re: [GENERAL] pg_dump behaves differently for different archive formats  (Stephen Frost <sfrost@snowman.net>)
List 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 by date:

Previous
From: Albe Laurenz
Date:
Subject: Re: [GENERAL] pg_dump behaves differently for different archive formats
Next
From: Andrew Dunstan
Date:
Subject: Re: building pdfs