Re: Edge case problem with pg_dump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Edge case problem with pg_dump
Date
Msg-id 5050.1022161825@sss.pgh.pa.us
Whole thread Raw
In response to Re: Edge case problem with pg_dump  ("D'Arcy J.M. Cain" <darcy@druid.net>)
Responses Re: Edge case problem with pg_dump  ("D'Arcy J.M. Cain" <darcy@druid.net>)
List pgsql-hackers
"D'Arcy J.M. Cain" <darcy@druid.net> writes:
> On May 22, 2002 10:28 am, you wrote:
>> Right now the only safe way to dump such a database is to use the
>> inserts-with-explicit-column-names option.  Someone was working on
>> extending COPY to allow a column name list, and as soon as that gets
>> done I intend to change pg_dump to specify a column name list in
>> COPY commands.  That should fix this problem.

> Do you mean issue COPY commands with fields or COPY out the fields in a 
> specific order by using the extension in pg_dump?

I intended that the dump scripts would say something like
COPY mytab(field1,field2,field3) FROM STDIN;

which would make it absolutely clear what the dump's field order is.
We can't solve it by reordering the fields while we dump, which is
what I think you mean by the other alternative: how is pg_dump to
guess what schema you are going to load the data into?  For example,
it should work to do a data-only dump and then reload into the existing
table structure.  So the dump script really needs to work for either
column ordering in the destination table, and that's why we need
explicit labeling of the field order in the script.

If we take this really seriously we might want to eliminate pg_dump's
-d (simple INSERT) option, and have only two dump formats: COPY with
field labels, or INSERT with field labels.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Ulrich Drepper
Date:
Subject: Re: Redhat 7.3 time manipulation bug
Next
From: Tom Lane
Date:
Subject: Re: tuples gone?