Re: possible design bug with PQescapeString()

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.

In response to

Browse pgsql-hackers by date

  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