Re: bytea char escaping

Stephen Robert Norris wrote:
> Ah, yes. I remember that page. The funny thing about it is that it
> doesn't actually say which strings _have_ to be escaped, just gives some
> examples...

"When entering bytea values, octets of certain values must be escaped
(but all octet values may be escaped) when used as part of a string
literal in an SQL statement. In general, to escape an octet, it is
converted into the three-digit octal number equivalent of its decimal
octet value, and preceded by two backslashes. Some octet values have
alternate escape sequences, as shown in Table 5-7."

I guess it could be more clear, but this paragraph refers to values
which must be escaped on input, and table 5-7 shows them. So they are
the examples of the values that must be escaped ;-)

>
> I always read the Table 5-8 example to indicate that 0-31, 127-255 and \
> have to be escaped, but it's not stated anywhere...

"Bytea output octets are also escaped. In general, each "non-printable"
octet decimal value is converted into its equivalent three digit octal
value, and preceded by one backslash. Most "printable" octets are
represented by their standard representation in the client character
set. The octet with decimal value 92 (backslash) has a special alternate
output representation. Details are in Table 5-8."

This one I think is pretty clear. It's discussing output, i.e. what the
client can expect to see coming from the server. So it's not saying you
need to escape those values, but it is saying that they will be sent to
you escaped.

But improved wording for the docs is always a welcome patch!

Joe