Re: COPY commands could use an enhancement. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: COPY commands could use an enhancement.
Date
Msg-id 15205.988645018@sss.pgh.pa.us
Whole thread Raw
In response to COPY commands could use an enhancement.  (Alfred Perlstein <bright@wintelcom.net>)
Responses Re: COPY commands could use an enhancement.  (Alfred Perlstein <bright@wintelcom.net>)
Re: COPY commands could use an enhancement.  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: COPY commands could use an enhancement.  (Joel Burton <jburton@scw.org>)
Re: COPY commands could use an enhancement.  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
Alfred Perlstein <bright@wintelcom.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.

Example: if we allow selective column import, what do we do with missing
columns?  Must COPY now be able to handle insertion of default-value
expressions?

I think it'd be better to put effort into an external data translation
utility that can deal with column selection, data reformatting, CR/LF
conversion, and all those other silly little issues that come up when
you need to move data from one DBMS to another.  Sure, we could make
the backend do some of this stuff, but it'd be more maintainable as a
separate program ... IMHO anyway.  I think that pgaccess and pgadmin
already have some capability in this line, BTW.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: v7.1.1 branched and released on Tuesday ...
Next
From: Tom Lane
Date:
Subject: Re: Re: v7.1.1 branched and released on Tuesday ...