Attached is a patch with documentation for the CSV mode of COPY patch
submitted yesterday.
cheers
andrew
Index: doc/src/sgml/ref/copy.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/ref/copy.sgml,v
retrieving revision
I have reviewed this patch. Basically, CSV is enabled by specifying
more than one delimiter character to COPY, e.g. DELIMITER ',"' or
DELIMITER ',""'. Is this API good for folks?
Prior to 7.2, a multi-character delimiter could be specified, but only
the first character was used. 7.2 release no
Bruce Momjian wrote:
I have reviewed this patch. Basically, CSV is enabled by specifying
more than one delimiter character to COPY, e.g. DELIMITER ',"' or
DELIMITER ',""'. Is this API good for folks?
(if not I'll be displeased, as it is what was the general consensus
about a month ago)
Prior
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>
> >I have reviewed this patch. Basically, CSV is enabled by specifying
> >more than one delimiter character to COPY, e.g. DELIMITER ',"' or
> >DELIMITER ',""'. Is this API good for folks?
> >
>
> (if not I'll be displeased, as it is what was
Bruce Momjian wrote:
Prior to 7.2, a multi-character delimiter could be specified, but only
the first character was used. 7.2 release notes state:
* COPY DELIMITERS string must be exactly one character (Tom)
I am a little worried about multibyte too, as you mentioned.
I am not sur
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 sev
Bruce Momjian said:
>> >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 C
Bruce Momjian <[EMAIL PROTECTED]> writes:
> 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.
I agree, this seems risky and not at all readable to s
Andrew Dunstan wrote:
> > 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.
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > 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.
>
> I agree, this seems risky
Bruce Momjian <[EMAIL PROTECTED]> writes:
> In other words, the string after CSV is optional. However, looking at
> the COPY syntax, there isn't any case where we have an optional string
> after a keyword. Is that OK?
Seems better to avoid it.
> However, this still has CSV using a two-character
Tom Lane said:
>>> COPY a FROM stdin WITH DELIMITER "," QUOTE '"' EQUOTE '"';
>> EQUOTE for embedded quote.
>
> ESCAPE would be better no? It's already a keyword ...
much better.
>
> BTW, don't forget that the syntax options have to be provided in psql's
> \copy as well. Did the patch cover tha
Bruce Momjian said:
>
> COPY tablename [ ( column [, ...] ) ]
> TO { 'filename' | STDOUT }
> [ [ WITH ]
> [ BINARY ]
> [ OIDS ]
> [ DELIMITER [ AS ] 'delimiter' ]
> [ NULL [ AS ] 'null string' ] ]
>
>
Andrew Dunstan wrote:
> Bruce Momjian said:
> >
> > COPY tablename [ ( column [, ...] ) ]
> > TO { 'filename' | STDOUT }
> > [ [ WITH ]
> > [ BINARY ]
> > [ OIDS ]
> > [ DELIMITER [ AS ] 'delimiter' ]
> > [ NU
Bruce Momjian said:
> Andrew Dunstan wrote:
>> Bruce Momjian said:
>> >
>> > COPY tablename [ ( column [, ...] ) ]
>> > TO { 'filename' | STDOUT }
>> > [ [ WITH ]
>> > [ BINARY ]
>> > [ OIDS ]
>> > [ DELIMITER [ AS ] 'delimit
On Mon, Apr 12, 2004 at 02:26:14 -0400,
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> a few points:
>
> . in CSV mode, NULL should default to '' - that was in what I sent in.
Postgres normally treats an empty string as an empty string. Are you sure
you really want it to be treated as a NULL by
Bruno Wolff III said:
> On Mon, Apr 12, 2004 at 02:26:14 -0400,
> Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>>
>> a few points:
>>
>> . in CSV mode, NULL should default to '' - that was in what I sent in.
>
> Postgres normally treats an empty string as an empty string. Are you
> sure you really wa
On Mon, Apr 12, 2004 at 08:07:12 -0400,
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> Otherwise, what will happen when we try to import into some non-text field
> for which '' is not a valid value?
I would expect the copy to fail as it does normally.
> Spreadsheets commonly represent missing v
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> On Mon, Apr 12, 2004 at 02:26:14 -0400,
> Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>> a few points:
>> . in CSV mode, NULL should default to '' - that was in what I sent in.
> Postgres normally treats an empty string as an empty string. Are you sure
Tom Lane wrote:
Bruno Wolff III <[EMAIL PROTECTED]> writes:
On Mon, Apr 12, 2004 at 02:26:14 -0400,
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
a few points:
. in CSV mode, NULL should default to '' - that was in what I sent in.
Postgres normally treats an empty string as an empty
Andrew Dunstan wrote:
> Tom Lane wrote:
>
> >Bruno Wolff III <[EMAIL PROTECTED]> writes:
> >
> >
> >>On Mon, Apr 12, 2004 at 02:26:14 -0400,
> >> Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>a few points:
> >>>. in CSV mode, NULL should default to '' - that was in what I sent in
On Mon, Apr 12, 2004 at 10:30:22 -0400,
Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> It is my understanding that \N is a valid column value (no backslash
> escape in CSV, right?), so we can't use it for NULL.
> The only thing I can think of is for NULL to be:
>
> ,,
>
> (no quotes) and a
Bruno Wolff III wrote:
> On Mon, Apr 12, 2004 at 10:30:22 -0400,
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > It is my understanding that \N is a valid column value (no backslash
> > escape in CSV, right?), so we can't use it for NULL.
> > The only thing I can think of is for NULL to be:
>
Bruce Momjian wrote:
It is my understanding that \N is a valid column value (no backslash
escape in CSV, right?), so we can't use it for NULL.
\ is not conventionally magical in CSVs in the general case. That
doesn't mean we couldn't use \N, but to me it would violate the
principle of least s
Andrew Dunstan wrote:
> In fact, in the patch I sent in, no quoted string is marked as null when
> being read (so even if you use \N as the null marker, "\N" will be that
> literal and not a null marker). And the null marker, whatever it is,
> should be made quote safe by us throwing an error if
Bruce Momjian wrote:
Andrew Dunstan wrote:
In fact, in the patch I sent in, no quoted string is marked as null when
being read (so even if you use \N as the null marker, "\N" will be that
literal and not a null marker). And the null marker, whatever it is,
should be made quote safe by us thr
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >Andrew Dunstan wrote:
> >
> >
> >>In fact, in the patch I sent in, no quoted string is marked as null when
> >>being read (so even if you use \N as the null marker, "\N" will be that
> >>literal and not a null marker). And the null marker, what
FYI, this CVS is turning into quite a job, but doing it right takes this
kind of effort.
---
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >Andrew Dunstan wrote:
> >
> >
> >>In fact, in the patch I sent in, no quoted s
28 matches
Mail list logo
