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).
> I don't like #2. Yeah, it's definitely messy --- for example, maybe é works in a latin1 database but is rejected when you try to restore into a DB with utf8 encoding. > 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. > #1 is the simplest to implement and to understand, > and I suspect it would break very little in practice, but others might > disagree with that assessment. We'd still have to decide what to do with pg_upgrade'd non-ASCII values, so there's messiness there too. Having charout() throw an error seems not very nice. regards, tom lane