Re: possible design bug with PQescapeString()

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: possible design bug with PQescapeString()
Дата
Msg-id 20060219172949.GF1323@svana.org
обсуждение исходный текст
Ответ на Re: possible design bug with PQescapeString()  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sun, Feb 19, 2006 at 12:13:48PM -0500, Tom Lane wrote:
> Florian Weimer <fw@deneb.enyo.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@svana.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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Config file for psql
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_service.conf