"Tomi NA" <hefest@gmail.com> writes:
> Basically, it comes down to three possibilities, doesn't it:
> 1.) use an existing library
> 2.) write a pgsql specific implementation
> 3.) forget about it and tend to other issues
> Personally, I don't really care if it's 1) or 2): I'm just afraid it's
> going to be 3).
> Is this a licencing issue (with regard to ICU beeing under the IBM
> public licence)?
Licensing is a concern --- IBM's appears to be not quite BSD enough.
Size and portability of the library are concerns. Performance is a
concern. Whether the patch makes the library required or optional is
a concern (if required, the portability issue becomes a whole lot more
urgent). Loss of existing functionality is a concern --- for instance,
if the patch is such that UTF8 becomes the only supported server
encoding, it'll probably be rejected forthwith.
> A plugin architecture (to get rid of licencing headaches) issue?
AFAIK making it a "plugin" won't alleviate anyone's licensing worries.
Certainly that's not going to answer if the library is GPL.
> To be perfectly honest, I've had to tackle so many problems with
> encodings during the years I'd make it punishable by law to use
> anything *but* UTF...but I'm not president of the Galaxy yet, Zaphod
> is. (-:
Well, the Japanese think that UTF8 is not the solution to all their
worries, so they won't be happy with a UTF8-only solution. Likewise,
those of us who only need single-byte character sets won't be very happy
with being forced to accept multi-byte processing overhead.
regards, tom lane