On Sat, May 7, 2011 at 12:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On the flip side, the risk of it flat-out blowing up seems pretty
>> small. For someone to invent their own version of wchar_t that uses
>> something other than Unicode code points would be pretty much pure
>> masochism, wouldn't it?
>
> Well, no, that's not clear. The C standard has pretty carefully avoided
> constraining the wchar_t representation, so implementors are free to do
> whatever is most convenient from the standpoint of their library routines.
> I could easily see somebody deciding to do something that wasn't quite
> Unicode because it let him re-use lookup tables designed for some other
> encoding, or some such.
>
> Now it's also perfectly possible, maybe even likely, that nobody's done
> that on any platform we care about. But I don't believe we know that
> with any degree of certainty. We definitely have not made any effort to
> establish whether it's true --- for example, we have no regression tests
> that address the point. (I think that collate.linux.utf8 touches on it,
> but we're a long way from being able to run that on non-glibc
> platforms...)
Well, since any problems in this are are going to bite us eventually
in 9.0+ even without any further action on our part, maybe it would be
wise to think up something we could add to the regression tests. That
would give us some immediate feedback from the buildfarm, and also
significantly improve the odds of someone compiling on a weird
platform noticing if things are broken.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
