Re: BUG #16236: Invalid escape encoding

PG Bug reporting form <noreply@postgresql.org> writes:
> From the documentation [0] about the encode function, the "escape" format
> should "convert zero bytes and high-bit-set bytes to octal sequences (\nnn)
> and doubles backslashes."
> However, executing "select encode(E'aaa\bccc', 'escape');" outputs
> "aaa\x08ccc", although according to the documentation I should get
> "aaa\010ccc".

No, I don't think so.  The \b gives rise to a byte with hex value 08
(that is, control-H or backspace) in the E'' literal, which converts
to the same byte value in the bytea value that gets passed to
encode().  Since that's not either a zero or a high-bit-set value,
encode() just repeats it literally in the text result, and you end
up with the same thing as if you'd just done

=# select E'aaa\bccc'::text;     
    text    
------------
 aaa\x08ccc
(1 row)

I think it must be psql itself that's choosing to represent the
backspace as \x08, because nothing in the backend does that.
(pokes around ... yeah, it's pg_wcsformat() that's doing it)

You could certainly make an argument that encode() ought to
backslashify all ASCII control characters, not only \0.  But
it's behaving as documented, AFAICS.

            regards, tom lane