From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Edge case problem with pg_dump |
Date: | 2002-05-23 13:50:25 |
Message-ID: | 5050.1022161825@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"D'Arcy J.M. Cain" <darcy(at)druid(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-05-23 14:09:56 | Re: tuples gone? |
Previous Message | Rajesh Kumar Mallah. | 2002-05-23 13:26:14 | Re: Further info : Very high load average but no cpu utilization ? |