Karsten Hilbert <Karsten.Hilbert@xxxxxxx> writes:
> Tom Lane wrote:
>> To make libpq UTF-16 capable, we'd have to change its API for all
>> strings; either make the strings counted rather than null-terminated,
>> or make the string elements wchar instead of char. After that we'd
>> have to hack the FE/BE protocol too (or more likely, require libpq
>> to translate UTF-16 to UTF-8 before sending to the server). I don't
>> foresee anyone doing any of this, at least not in the near term.
> Is there any *real* loss of functionality in not supporting
> UTF-16 ?
Functionality, no: UTF-16 and UTF-8 are functionally equivalent by definition.
I think the reason that it's started to come up lately is that Windows
supports UTF-16 better than UTF-8 (whereas the reverse is true on most
Unixish platforms).
If libpq were the only available API then I'd be more concerned about
making it handle this somehow. But if you're working in, say, Java
then this issue is all taken care of for you anyway. There are enough
other Unix-centricities in libpq that this hardly seems the worst.
Possibly someone will be motivated to start a project to design a
Windows client library from scratch ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
