>> I used to had a customer who needs to have different client and
>> database encoding than the default. That is, a slightly different
>> mapping between Shift-JIS and other database encoding. Due to
>> unfortunate historical reasons, there are several Shift-JIS variants
>> (in addition to the standard defined by government, there are IBM, NEC
>> and Microsoft versions). This is the reason why I wanted to have the
>> functionality at that time. I'm not sure the customer still uses the
>> functionality, but it is possible that there are other users who have
>> similar use cases, since the Shift-JIS variants are still used.
>
> Hm. Odd that we've not heard complaints about the removal of
> CONVERT(... USING ...), then.
Yeah, I'm not sure the customer updated to the newer version of
PostgreSQL.
> I think it would be a good idea at least to put back some equivalent
> of CONVERT(... USING ...), if for no other reason than that it would
> ease testing. As I understood it, the argument to remove it was not
> that the functionality was bad, but that we were using a SQL-standard
> syntax for what we concluded was not SQL-standard functionality.
> I'd propose putting it back with a syntax of, say,
>
> convert_with(input bytea, conversion_name text) returns bytea
>
> As for the client encoding conversion case, I still say a
> search-path-based lookup is a horrible idea, and furthermore there
> seems no very good reason why it has to be restricted to default
> conversions. Aside from other arguments, that tends to push people
> to mark *every* conversion as default, which is outright silly if
> you have several competing ones.
>
> As a sketch of an alternative, consider inventing a GUC named
> preferred_conversions or some such, which is a list of
> possibly-schema-qualified conversion names. When establishing an
> original or new value of client_encoding, we look through the list
> for the first entry that exists and performs the desired encoding
> conversion (whether or not it is default). If there is no match,
> look up the (unique) default conversion for the encoding pair, and
> use that. (Obviously this has to be done twice, once for each
> direction, when setting up client encoding conversions.) We could
> apply the same rules for identifying which specific conversion to use
> in convert() and siblings.
Sounds good to me.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
