Jim C. Nasby wrote:
On Tue, Apr 17, 2007 at 02:28:18PM -0400, Tom Lane wrote:
I doubt that supporting a single multibyte character would be an
interesting extension --- if we wanted to do anything at all there, we'd
just generalize the delimiter to be an arbitrary string. But it would
certai
On Tue, Apr 17, 2007 at 02:28:18PM -0400, Tom Lane wrote:
> I doubt that supporting a single multibyte character would be an
> interesting extension --- if we wanted to do anything at all there, we'd
> just generalize the delimiter to be an arbitrary string. But it would
> certainly slow down COPY
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > The message in question should be something like:
> > "COPY delimiter must be a single ASCII character"
>
> If we phrase it like that we should enforce it like that --- ie, reject
> high-bit-set characters.
>
> But I'm a bit hesitant to do so, becau
Tatsuo Ishii wrote:
> > On looking at the code, there's another issue: the CSV escape and quote
> > characters are assumed to be the same in client and server encodings,
> > because they're checked for before we do transcoding. This pretty much
> > restricts them to be ASCII.
> >
> >
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> The message in question should be something like:
> "COPY delimiter must be a single ASCII character"
If we phrase it like that we should enforce it like that --- ie, reject
high-bit-set characters.
But I'm a bit hesitant to do so, because it actually d
> On looking at the code, there's another issue: the CSV escape and quote
> characters are assumed to be the same in client and server encodings,
> because they're checked for before we do transcoding. This pretty much
> restricts them to be ASCII.
>
> regards, tom lane
+1.
On looking at the code, there's another issue: the CSV escape and quote
characters are assumed to be the same in client and server encodings,
because they're checked for before we do transcoding. This pretty much
restricts them to be ASCII.
regards, tom lane
-
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Mark Dilger wrote:
>> I'm working on fixing bugs relating to multibyte character encodings.
>> I wasn't sure whether this was a bug or not. I don't think we should
>> use the phrasing "COPY delimiter must be a single character" when, in
>> utf8 lan
Mark Dilger wrote:
Andrew Dunstan wrote:
Mark Dilger wrote:
The \COPY command rejects multibyte delimiters. Is this intentional
behavior?
It is certainly a known limitation, and I suspect removing it could
add non-trivial overhead to the input processing.
What is the use case for using su
Andrew Dunstan wrote:
Mark Dilger wrote:
The \COPY command rejects multibyte delimiters. Is this intentional
behavior?
It is certainly a known limitation, and I suspect removing it could add
non-trivial overhead to the input processing.
What is the use case for using such a delimiter?
I'
Mark Dilger wrote:
The \COPY command rejects multibyte delimiters. Is this intentional
behavior?
It is certainly a known limitation, and I suspect removing it could add
non-trivial overhead to the input processing.
What is the use case for using such a delimiter?
cheers
andrew
-
The \COPY command rejects multibyte delimiters. Is this intentional
behavior?
Here is an example of the behavior:
[EMAIL PROTECTED] ~ $ touch foo
[EMAIL PROTECTED] ~ $ psql -p
Welcome to psql 8.3devel, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\
12 matches
Mail list logo
