Le Monday 07 April 2008 21:04:26 Andrew Dunstan, vous avez écrit :
> Quite apart from any other reason why not, this would be a horrid hack
> and is just the sort of "feature" we rightly eschew, IMNSHO. COPY is
> designed as a bulk load/unload facility. It's fragile enough in that role.
And my main concern would still be left as-is, COPY wouldn't have any facility
to cope with data representation not matching what datatype input functions
want to read. More often than not, you get this kind of data from another
system, so in a deterministic way, and you want a chance to transform their
representation just before PostgreSQL parses it.
May I try to insist on my second syntax proposal form:
COPY destination_table(col1, col2, col3)
USING (field1, field2 || field3, myfunc(field4, field5))
FROM 'file.txt'
WITH ...
This allows for the case I'm concerned with to be taken care of, AND the other
case pointed out by several posters on this thread too. N input fields, M
stored columns, any line to row transformation (after same column splitting
as of now), any column pre-parsing through SQL callable functions --- myfunc
is called before feeding col3%ROWTYPE input function, e.g.
And no support (that I see) for optional second storage system back door.
Comments?
--
dim
