Re: BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading - Mailing list pgsql-bugs

From Stefan Kaltenbrunner
Subject Re: BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Date
Msg-id 4C1105F9.1060805@kaltenbrunner.cc
Whole thread Raw
In response to Re: BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading  (Stephen Frost <sfrost@snowman.net>)
List pgsql-bugs
Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> On 10/06/10 16:21, Robert Haas wrote:
>>> I do agree that the human readability of pg_dump is an asset in many
>>> situations - I have often dumped out the DDL for particular objects
>>> just to look at it, for example.  However, I emphatically do NOT agree
>>> that leaving someone with a 500MB dump file (or, for some people on
>>> this list, a whole heck of a lot larger than that) that has to be
>>> manually edited to reload is a useful behavior.  It's a huge pain in
>>> the neck.
>
>> Much easier to do a schema-only dump, edit that, and dump data separately.
>
> That gets you out of the huge-file-to-edit problem, but the performance
> costs of restoring a separate-data dump are a pretty serious
> disadvantage.  We really should do something about that.

well that is an argument for providing not only --schema-only and
--data-only but rather three options one for the table definitions, one
for the data and one for all the constraints and indexes. So basically
what pg_dump is currently doing anyway but just exposed as flags.


Stefan

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Next
From: Thom Brown
Date:
Subject: Re: Beta 2 build issue