On 12/3/21 14:42, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 12/3/21 14:12, Tom Lane wrote:
>>> I can think of at least three ways we might address this:
>>>
>>> * Forbid all non-ASCII values for type "char". This results in
>>> simple and portable semantics, but it might break usages that
>>> work okay today.
>>>
>>> * Allow such values only in single-byte server encodings. This
>>> is a bit messy, but it wouldn't break any cases that are not
>>> problematic already.
>>>
>>> * Continue to allow non-ASCII values, but change charin/charout,
>>> char_text, etc so that the external representation is encoding-safe
>>> (perhaps make it an octal or decimal number).
>> Is #3 going to change the external representation only
>> for non-ASCII values? If so, that seems OK.
> Right, I envisioned that ASCII behaves the same but we'd use
> a numeric representation for high-bit-set values. These
> cases could be told apart fairly easily by charin(), since
> the numeric representation would always be three digits.
OK, this seems the most attractive. Can we also allow 2 hex digits?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
