Re: A proper fix for the conversion-function problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: A proper fix for the conversion-function problem
Date
Msg-id 14646.1115182145@sss.pgh.pa.us
Whole thread Raw
In response to Re: A proper fix for the conversion-function problem  ("John Hansen" <john@geeknet.com.au>)
List pgsql-hackers
"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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: inclusions WAS: Increased company involvement
Next
From: Alvaro Herrera
Date:
Subject: Re: inclusions WAS: Increased company involvement