Skip site navigation (1) Skip section navigation (2)

Re: Bug in UTF8-Validation Code?

From: Mark Dilger <pgsql(at)markdilger(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Bug in UTF8-Validation Code?
Date: 2007-04-02 22:02:21
Message-ID: 46117D6D.7050705@markdilger.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Mark Dilger <pgsql(at)markdilger(dot)com> writes:
>>> pgsql=# select chr(14989485);
>>> chr
>>> -----
>>> 中
>>> (1 row)
> 
> Is there a principled rationale for this particular behavior as
> opposed to any other?
> 
> In particular, in UTF8 land I'd have expected the argument of chr()
> to be interpreted as a Unicode code point, not as actual UTF8 bytes
> with a randomly-chosen endianness.
> 
> Not sure what to do in other multibyte encodings.

"Not sure what to do in other multibyte encodings" was pretty much my rationale 
for this particular behavior.  I standardized on network byte order because 
there are only two endianesses to choose from, and the other seems to be a more 
surprising choice.

I looked around on the web for a standard for how to convert an integer into a 
valid multibyte character and didn't find anything.  Andrew, Supernews has said 
upthread that chr() is clearly wrong and needs to be fixed. If so, we need some 
clear definition what "fixed" means.

Any suggestions?

mark

In response to

Responses

pgsql-hackers by date

Next:From: Mark DilgerDate: 2007-04-02 22:05:27
Subject: Re: Bug in UTF8-Validation Code?
Previous:From: Tom LaneDate: 2007-04-02 21:42:14
Subject: Re: Questions about pid file creation code

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group