Re: libpq Unicode support?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: libpq Unicode support?
Date: 2005-04-22 22:10:58
Message-ID: 18140.1114207858@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2005-04-22 22:13:40 Re: pg_dump serial UNIQUE NOT NULL PRIMARY KEY
Previous Message Bruce Momjian 2005-04-22 22:08:33 Re: libpq Unicode support?