Greg Stark wrote: > On Mon, Aug 31, 2009 at 12:01 PM, Heikki > Linnakangas<heikki.linnakan...@enterprisedb.com> wrote: >> Hmm, perhaps we should follow what we did to chr() and ascii(): map the >> integer to unicode code points if the database encoding is UTF-8, and >> restrict the range to 0..127 for other multi-byte encodings. > > I don't think we even have to worry about the database's encoding. > 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. > > That allows people to treat it as a 1-byte integer type which happens > to allow input or output as a single ascii character which is > convenient sometimes.
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 committed the rest of the patch, without the "char" changes) -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
