| 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: | Whole Thread | Raw Message | 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 |