Re: COPY for CSV documentation - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: COPY for CSV documentation
Date
Msg-id 200404110252.i3B2q1X08292@candle.pha.pa.us
Whole thread Raw
In response to Re: COPY for CSV documentation  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: COPY for CSV documentation
Re: COPY for CSV documentation
List pgsql-patches
Andrew Dunstan wrote:
> >>I am not sure that CSVs even make sense in a multibyte world. If not, it
> >>would make sense to disable it in such a case.
> >>
> >>(Is that your only worry?)
> >>
> >>
> >
> >Yes, my worry is that someone will use a multibyte character that the
> >system sees as several bytes and enters CSV mode.
> >
>
>
> How about if we specify it explicitly, like BINARY, instead of it being
> implied by the length of DELIMITER?
>
> COPY a FROM stdin CSV DELIMITER ',"';
>
> That would make the patch somewhat more extensive, but maybe not hugely
> more invasive (I tried to keep it as uninvasive as possible). I could do
> that, I think.

That's what I was wondering.  Is triggering CSV for multi-character
delimiters a little too clever?  This reminds me of the use of LIMIT X,Y
with no indication which is limit and which is offset.

We certainly could code to prevent the multibyte problem I mentioned,
but should we?

I am thinking just:

> COPY a FROM stdin WITH CSV ',"';

or

> COPY a FROM stdin WITH DELIMITER "," QUOTE '"' EQUOTE '"';

EQUOTE for embedded quote.  These are used in very limited situations
and don't have to be reserved words or anything.

I can help with these changes if folks like them.

--
  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, Pennsylvania 19073

pgsql-patches by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: COPY for CSV documentation
Next
From: "Andrew Dunstan"
Date:
Subject: Re: COPY for CSV documentation