>> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers