On 05.09.2013 15:47, Peter Eisentraut wrote:
Can we consider getting rid of the SQL_ASCII server-side "encoding"? I don't see any good use for it, and it's often a support annoyance, and it leaves warts all over the code. This would presumably be a multi-release effort.
I think "warts all over the code" is an overstatement. There aren't that many places in the code that care about SQL_ASCII, and they're all related to encoding conversions.
As a first step in accommodating users who have existing SQL_ASCII databases, we could change SQL_ASCII into a real encoding with conversion routines to all other encodings that only convert 7-bit ASCII characters. That way, users who use SQL_ASCII as real ASCII or don't care could continue to use it. Others would be forced to either set SQL_ASCII as the client encoding or adjust the encoding on the server. On the client side, the default libpq client "encoding" SQL_ASCII would be renamed to something like SAME or whatever, so the behavior would stay the same. Other ideas? Are there legitimate uses for SQL_ASCII?
One use is if you want to use some special encoding that's not supported by PostgreSQL, and you want PostgreSQL to just regurgitate any strings as is. It's not common, but would be strange to remove that capability altogether, IMHO.
I agree it would be nice to have a "real" ASCII encoding, which only accepts 7-bit ASCII characters. And it would be nice if "SQL_ASCII" was called something else, like "UNDEFINED" or "BYTE_PER_CHAR", to make the meaning more clear. But I'm not in favor of deprecating it altogether.
Also, during backend initialization there is a phase where client_encoding has not been set yet, and we don't do any conversions yet. That's exactly what SQL_ASCII means, so even if we get rid of SQL_ASCII, we'd still need to have some encoding value in the backend to mean that intermediate state.
- Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
