From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Florian Weimer <fw(at)deneb(dot)enyo(dot)de>, Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: possible design bug with PQescapeString() |
Date: | 2006-02-19 17:29:49 |
Message-ID: | 20060219172949.GF1323@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 19, 2006 at 12:13:48PM -0500, Tom Lane wrote:
> Florian Weimer <fw(at)deneb(dot)enyo(dot)de> writes:
> > Uh-oh, this is my fault. PQescapeString should escape all characters
> > greater than 126.
>
> No, that doesn't work, because the de-escaping on the backend side
> happens *after* conversion to the backend encoding. If you insert escapes
> into the middle of multibyte characters then you break the conversion.
Well, most encodings provide an easy way to determine leader and
follower characters. The PQmblen() and related functions can help here.
Something like:
if( PQmblen(enc,ptr) > 1 )
copy bytes
else if( SQL_STR_DOUBLE( *ptr ) )
etc...
Assuming there are no multibyte string terminators... And assuming you
actually know what encoding the server expects.
However, the real solution seems to me to be to use something like
PQexecParams and ship the arguments outside the query string, thus
avoiding the issue entirely.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-02-19 17:41:21 | Re: pg_service.conf |
Previous Message | Jim C. Nasby | 2006-02-19 17:25:17 | Re: [HACKERS] Config file for psql |