Re: prevent invalidly encoded input

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: prevent invalidly encoded input
Date: 2007-09-12 03:05:16
Message-ID: 8523.1189566316@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> Also, I'd kinda like to have the check-for-high-bit optimization in
>> scan.l too --- some people do throw big literals at the thing.
>>
> OK, will do. Am I correct in thinking I don't need to worry about the
> <xeescape> case, only the <xeoctesc> and <xehexesc> cases?

[ squint ... ] Hm, wouldn't bet on it. That leads to
unescape_single_char(), which is fine for the cases that it explicitly
knows about (\b and so on), but what if the following byte has the
high bit set? Not only would that pass through a high bit to the
output, but very possibly this results in disassembling a multibyte
input character.

So it looks like you need to recheck if unescape_single_char sees a
high-bit-set char.

You should take a second look at the COPY code to see if there's a
similar case there --- I forget what it does with backslash followed
by non-digit.

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2007-09-12 03:12:21 Re: Version in Japanese FAQ is wrong (was [COMMITTERS] pgsql: Stamp releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20.)
Previous Message ITAGAKI Takahiro 2007-09-12 02:13:42 Version in Japanese FAQ is wrong (was [COMMITTERS] pgsql: Stamp releases 8.2.5, 8.1.10, 8.0.14, 7.4.18, 7.3.20.)