Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Greg Stark wrote:
>> Just make the textual representation of "char" be \xxx (or perhaps we
>> could switch to \xHH now) if the value isn't a printable ascii
>> character. As long as "char" reads that in properly it doesn't matter
>> if it's not a reasonable multibyte character.
> Hmm, seems reasonable. However, it would mean that "\123" would be
> interpreted differently in the new version than the old. In previous
> versions the extra characters are truncated and the value becomes '\',
> whereas the new interpretation would be 'S'.
I think that Greg's proposal might be the sanest solution. Aside from
avoiding the encoding problem, it would give us a more reasonable text
representation for byte value 0 (ie, '\000' not ''). We could probably
address the compatibility risk sufficiently by having charin throw error
whenever the input is more than one byte long and does NOT have the form
'\nnn'. This would also respond to the discussion of bug #5028 about
how charin ought not silently accept multicharacter input.
regards, tom lane
