On 12/3/21 14:42, Tom Lane wrote: > Andrew Dunstan <and...@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
