Skip site navigation (1) Skip section navigation (2)

Re: psql enhancement idea

From: "Uwe C(dot) Schroeder" <uwe(at)oss4u(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: psql enhancement idea
Date: 2004-10-21 22:18:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Hash: SHA1

On Thursday 21 October 2004 03:03 pm, Tom Lane wrote:
> "Uwe C. Schroeder" <uwe(at)oss4u(dot)com> writes:
> > On Thursday 21 October 2004 12:40 pm, Tom Lane wrote:
> >> I don't think that conclusion follows from that premise.  In recent
> >> pg_dump versions (any that use a column list with COPY, which I think is
> >> 7.3 or later) there is no fundamental disadvantage to using COPY; it
> >> should be semantically equivalent to INSERT-with-column-list commands.
> >
> > The reason is that I made changes to the schema, i.e. changed the ordinal
> > position of columns and added some columns. Since the positioning of the
> > columns isn't the same anymore a copy will fail.
> No, it won't, not if you use a column list.

Ahhh - I see what you mean, thanks for that hint.

A little remark then: the pg_dump manpage (7.4.3) states

              Dump  data as INSERT commands with explicit column names (INSERT
              INTO table (column, ...) VALUES ...). This will make restoration
              very  slow,  but  it is necessary if you desire to rearrange the
              column ordering.

Maybe that should be fixed then. I was used to do the full insert statements 
(ok, I've been using postgres long before it even had SQL) - maybe a old 
habit then...


- --
Open Source Solutions 4U, LLC	2570 Fleetwood Drive
Phone:  +1 650 872 2425		San Bruno, CA 94066
Cell:   +1 650 302 2405		United States
Fax:    +1 650 872 2417
Version: GnuPG v1.2.3 (GNU/Linux)


In response to


pgsql-admin by date

Next:From: Tom LaneDate: 2004-10-21 22:50:06
Subject: Re: psql enhancement idea
Previous:From: Tom LaneDate: 2004-10-21 22:03:16
Subject: Re: psql enhancement idea

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group