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
signature.asc
Description: This is a digitally signed message part.
