On 12/05/21 12:01, Tom Lane wrote: > regression=# select '\'::bytea; > ERROR: invalid input syntax for type bytea > > which would be incompatible with "char"'s existing behavior. But as > long as we don't do that, I'd be okay with having high-bit-set char > values map to backslash-followed-by-three-octal-digits, which is > what bytea escape format would produce.
Is that a proposal to change nothing about the current treatment of values < 128, or just to avoid rejecting bare '\'? It seems defensible to relax the error treatment of bare backslash, as it isn't inherently ambiguous; it functions more as an "are you sure you weren't starting to write an escape sequence here?" check. If it's a backslash with nothing after it and you assume the user wrote what they meant, then it's not hard to tell what they meant. If there's a way to factor out and reuse the good parts of byteain, that would mean '\\' would also be accepted to mean a backslash, and the \r \n \t usual escapes would be accepted too, and \ooo and \xhh. >> Maybe have charin >> accept either bytea-escaped or bytea-hex form too. > > That seems like more complexity than is warranted I think it ends up being no more complexity at all, because a single octet in bytea-hex form looks like \xhh, which is exactly what a single \xhh in bytea-escape form looks like. I suppose it's important to consider what comparisons like c = '\' and c = '\\' mean, which should be just fine when the type analysis produces char = char or char = unknown, but could be surprising if it doesn't. Regards, -Chap
