Re: The "char" type versus non-ASCII characters

On 12/05/21 14:51, Tom Lane wrote:
> Uh, what?
> 
> regression=# select '\n'::bytea;
> ERROR:  invalid input syntax for type bytea

Wow, I was completely out to lunch there somehow. Sorry. None of those
other escaped forms are known to byteain, other than '\\' and ''''
according to table 8.7. I can't even explain why I thought that.

> I'm confused by this statement too.  AFAIK the alternatives in
> bytea are \xhh or \ooo:

Here I think I can at least tell where I went wrong; I saw both an
octal and a hex column in table 8.7, which I saw located under the
"bytea escape format" heading, and without testing carefully enough,
I assumed it was telling me that either format would be recognized on
input, which would certainly be possible, but clearly I was carrying
over too many assumptions from other escape formats where I'm used to
that being the case. If I wanted to prevent another reader making my
exact mistake, I might re-title those two table columns to be
"In bytea escape format" and "In bytea hex format" to make it more clear
the table is combining information for both formats.

I'm sure I did test SELECT '\x41'::bytea, but that proved nothing,
being simply interpreted as the hex input format. I should have
tried SELECT 'A\x41'::bytea, and would have immediately seen it rejected.

I've just looked at datatypes.sgml, where I was expecting to see that
table 8.7 actually falls outside of the sect2 for "bytea escape format",
and that I had simply misinterpreted it because the structural nesting
isn't obvious in the rendered HTML.

But what I found was that the table actually /is/ nested inside the
"bytea escape format" section, and in the generated HTML it is within
the div for that section, and the table's own div has the ID
DATATYPE-BINARY-SQLESC.

The change history there appears complex. The table already existed
at the time of a2a8c7a, which made a "bytea escape format" sect2 out
of the existing text that included the table, and added a separate
"bytea hex format" sect2. But the table at that point showed only the
input and output representations for the escape format, didn't say
anything about hex format, and wasn't touched in that commit.

Nine years later, f77de4b changed the values in the rightmost column
to hex form, but only because that was then the "output representation"
column and the default output format had been changed to hex.

Five months after that, f10a20e changed the heading of that column
from "output representation" to "hex representation", probably because
the values in that column by then were hex. So it ended up as a table
that is structurally part of the "bytea escape format" section,
whose rightmost column shows a hex format, and therefore (ahem)
could suggest to a reader (who doesn't rush to psql and test it
thoroughly) that a hex format is accepted there.

Still, I could have avoided that if I had better tested my reading
first.

Regards,
-Chap