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

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