Re: Unexpected behaviour of encode() - Mailing list pgsql-general

From Tom Lane
Subject Re: Unexpected behaviour of encode()
Date
Msg-id 10292.1364523970@sss.pgh.pa.us
Whole thread Raw
In response to Re: Unexpected behaviour of encode()  (Jasen Betts <jasen@xnet.co.nz>)
List pgsql-general
Jasen Betts <jasen@xnet.co.nz> writes:
> On 2013-03-26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The manual says that 'escape' encoding "merely outputs null bytes as
>> \000 and doubles backslashes".

>> (Having said that, I wonder though if "escape" doesn't need more
>> thought.  The output is only valid text in SQL_ASCII or single-byte
>> encodings, otherwise there's risk of encoding violations.)

> it does that too, since as long as I can remember.
> I used decode-hex here so it'll work on older version of pg.

Hah ... that's what I get for believing the manual ;-).  The code
comments tell the truth:

 * We must escape zero bytes and high-bit-set bytes to avoid generating
 * text that might be invalid in the current encoding, or that might
 * change to something else if passed through an encoding conversion
 * (leading to failing to de-escape to the original bytea value).
 * Also of course backslash itself has to be escaped.

It appears that the manual's statement was correct before 8.3, but
when somebody fixed the code to deal with the encoding issue, they
didn't fix the manual.  I'll go improve that ...

            regards, tom lane


pgsql-general by date:

Previous
From: Chris Angelico
Date:
Subject: Re: Money casting too liberal?
Next
From: "Severn, Chris"
Date:
Subject: subscribe