Skip site navigation (1) Skip section navigation (2)

Re: CopyReadLineText optimization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: CopyReadLineText optimization
Date: 2008-03-06 19:21:03
Message-ID: 20191.1204831263@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> Andrew Dunstan wrote:
>> We currently make the following assumption in the code:
>> 
>> * These four characters, and the CSV escape and quote characters, are
>> * assumed the same in frontend and backend encodings.
>> 
>> The four characters are the carriage return, line feed, backslash and dot.
>> 
>> I think the requirement might well actually be somewhat stronger than 
>> that: i.e. that none of these will appear as a non-first byte in any 
>> multi-byte client encoding character.

> No, we don't require that, and we do handle it correctly.

I believe we *have to* handle it correctly, because backslash actually
does appear as a non-first byte in SJIS or some other Far Eastern
encoding.  In the CSV case such a restriction would be untenable anyway.

BTW, I notice that the code allows CSV escape and quote characters that
have the high bit set (in single-byte server encodings that is).  Is
this a good idea?  It seems like such are extremely unlikely to be the
same in two different encodings.  Maybe we should restrict to the ASCII
range?  Especially if the client encoding is multibyte ...

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2008-03-06 19:24:19
Subject: Re: CopyReadLineText optimization
Previous:From: Tom LaneDate: 2008-03-06 19:10:40
Subject: Re: 8.3.0 Core with concurrent vacuum fulls

pgsql-patches by date

Next:From: Andrew DunstanDate: 2008-03-06 19:24:19
Subject: Re: CopyReadLineText optimization
Previous:From: Heikki LinnakangasDate: 2008-03-06 18:52:11
Subject: Re: CopyReadLineText optimization

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group