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 that?
No,
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' ]
[ NULL [ AS ] 'null
Bruce Momjian said:
Andrew Dunstan wrote:
Bruce Momjian said:
COPY tablename [ ( column [, ...] ) ]
TO { 'filename' | STDOUT }
[ [ WITH ]
[ BINARY ]
[ OIDS ]
[ DELIMITER [ AS ] 'delimiter' ]
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 [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
you
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.
Postgres
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
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 it
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
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 string is
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
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.
I can help with these
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 and not at
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
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
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 the general
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
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
22 matches
Mail list logo
