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

Re: COPY commands could use an enhancement.

From: Alfred Perlstein <bright(at)wintelcom(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: COPY commands could use an enhancement.
Date: 2001-04-30 16:30:04
Message-ID: 20010430093004.G18676@fw.wintelcom.net (view raw or flat)
Thread:
Lists: pgsql-hackers
* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [010430 08:37] wrote:
> Alfred Perlstein <bright(at)wintelcom(dot)net> writes:
> > It would be very helpful if the COPY command could be expanded
> > in order to provide positional parameters.
> 
> I think it's a bad idea to try to expand COPY into a full-tilt data
> import/conversion utility, which is the direction that this sort of
> suggestion is headed in.  COPY is designed as a simple, fast, reliable,
> low-overhead data transfer mechanism for backup and restore.  The more
> warts we add to it, the less well it will serve that purpose.

Honestly it would be hard for COPY to be any more less serving of
people's needs, it really makes sense for it to be able to parse
positional paramters for both speed and correctness.

> Example: if we allow selective column import, what do we do with missing
> columns?

What is already done, if you initiate a copy into a 5 column table
using only 4 columns of copy data the fifth is left empty.

> Must COPY now be able to handle insertion of default-value
> expressions?

No, copy should be what it is simple but at the same time useful
enough for bulk transfer without painful contortions and fear
of modifying tables.

-- 
-Alfred Perlstein - [alfred(at)freebsd(dot)org]
Represent yourself, show up at BABUG http://www.babug.org/

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-04-30 17:25:32
Subject: Re: COPY commands could use an enhancement.
Previous:From: Peter EisentrautDate: 2001-04-30 16:12:36
Subject: Re: v7.1.1 branched and released on Tuesday ...

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