Kris Jurka wrote:
>
>
> On Mon, 29 Nov 2004, Andrew Dunstan wrote:
>
> > Longer term I'd like to be able to have a command parameter that
> > specifies certain fields as multiline and for those relax the line end
> > matching restriction (and for others forbid multiline altogether). That
> > would be a TODO for 8.1 though, along with optional special handling for
> > first line column headings.
> >
>
> Endlessly extending the COPY command doesn't seem like a winning
> proposition to me and I think if we aren't comfortable telling every user
> to write a script to pre/post-process the data we should instead provide a
> bulk loader/unloader that transforms things to our limited COPY
> functionality. There are all kinds of feature requests I've seen
> along these lines that would make COPY a million option mess if we try to
> support all of it directly.
>
> - skipping header rows
> - skipping certain data file columns
> - specifying date formats
> - ignoring duplicates
> - outputting an arbitrary SELECT statement
Agreed. There are lots of wishes for COPY and it will become bloated if
we do them all.
I am concerned someone will say, "Oh, I know the CSV format and I might
load the data into another database someday so I will always use CVS"
not knowing it isn't a 100% consistent format. I think we need to
issues a warning if a \r or \n is output by COPY CSV just so people
understand the limitation. We can then reevaluate where we need to go
for 8.1.
Open item updated:
* warn on COPY TO ... CSV with \r,\n in data
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
