From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
Subject: | Re: PQescapeBytea is not multibyte aware |
Date: | 2002-04-05 18:33:32 |
Message-ID: | 3CADEDFC.508@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
>
> OTOH, I was surprised to read your message because I had assumed the
> damage was being done much further upstream, viz during collection of
> the query string by pq_getstr(). Do we need to think twice about that
> processing, as well?
>
I just looked in pq_getstr() I see:
#ifdef MULTIBYTE
p = (char *) pg_client_to_server((unsigned char *) s->data, s->len);
if (p != s->data) /* actual conversion has been done? */
and in pg_client_to_server I see:
if (ClientEncoding->encoding == DatabaseEncoding->encoding)
return s;
So I'm guessing that in Tatsuo's case, both client and database encoding
are the same, and therefore the string was passed as-is downstream. I
think you're correct that in a client/database encoding mismatch
scenario, there would be bigger problems. Thoughts on this?
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-04-05 18:40:52 | Re: PQescapeBytea is not multibyte aware |
Previous Message | Tom Lane | 2002-04-05 18:21:41 | Re: 16 parameter limit |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-04-05 18:40:52 | Re: PQescapeBytea is not multibyte aware |
Previous Message | Tom Lane | 2002-04-05 18:21:41 | Re: 16 parameter limit |