Errm.. UTF-16/32

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailtogsql-hackers-owner@postgresql.org] On Behalf Of John Hansen
> Sent: Wednesday, May 04, 2005 1:22 PM
> To: Tom Lane; Tatsuo Ishii
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] A proper fix for the
> conversion-function problem
>
> > Are there any encodings we care about that require embedded zero
> bytes?
>
> UTF-8 does!
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

"John Hansen" <john@geeknet.com.au> writes:
> Errm.. UTF-16/32

Ah, I thought that was what you meant.

Right now we have a *ton* of problems with supporting encodings that
need embedded zero bytes, because there are APIs all over the place
that use zero-terminated strings. I don't foresee that it will ever
be worth the trouble to make such encodings work natively inside the
backend. It might possibly be worth the trouble to allow 'em as client
encodings ... but that would require fixing not just the encoding
converters, but the FE/BE protocol, libpq, psql, pg_dump, and who knows
what other client-side software.

If we're willing to make a commitment to go down that long hard road,
it'd make sense to define the encoding conversion API to support strings
with embedded nulls. Personally I'm agin it --- I think that the needed
development effort would be better spent elsewhere. But my personal
needs don't stretch further than 7-bit ASCII so maybe I'm not the best
guy to make such decisions.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly