| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Correctly producing array literals for prepared statements |
| Date: | 2011-02-23 15:31:57 |
| Message-ID: | 28918.1298475117@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> On 23.02.2011 17:16, Andrew Dunstan wrote:
>> On 02/23/2011 10:09 AM, Peter Geoghegan wrote:
>>> I'm pretty sure all of the client encodings Tatsuo mentions are ASCII
>>> supersets.
>> They are not. It's precisely because they are not that they are not
>> allowed as server encodings.
> In the supported client-only encodings, the *first* byte of a multi-byte
> character is guaranteed to have the high bit set, but the subsequent
> bytes are not.
And to be even more specific: the problem with the client-only encodings
is that some of them allow the byte values corresponding to "\" and
other escaping-critical characters to appear as non-first bytes in a
multibyte character. This is nasty because you have to be aware of the
encoding to do escaping correctly and not break the data. And as soon
as the server and client don't agree on what the encoding is, you have
the potential for SQL-injection security holes, not just confused data.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2011-02-23 15:34:06 | Re: Correctly producing array literals for prepared statements |
| Previous Message | Greg Stark | 2011-02-23 15:25:00 | Re: Correctly producing array literals for prepared statements |