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
