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
