"John Hansen" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly