Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> Earlier in this thread, MauMau pointed out that we can't do encoding
> conversions until we have connected to the database because you need to
> read pg_conversion for that. That's because we support creating custom
> conversions with CREATE CONVERSION. Frankly, I don't think anyone cares
> about that feature. If we just dropped the CREATE/DROP CONVERSION
> feature altogether and hard-coded the conversions we have, there would
> be close to zero complaints. Even if you want to extend something around
> encodings and conversions, the CREATE CONVERSION interface is clunky.
> Firstly, conversions are per-database, and even schema-qualified, which
> just seems like an extra complication. You'll most likely want to modify
> the conversion across the whole system. Secondly, rather than define a
> new conversion between encodings, you'll likely want to define a whole
> new encoding with conversions to/from existing encodings, but you can't
> do that anyway without hacking the source code.
There's certainly something to be said for that position. If there were
any prospect of extensions defining new encodings someday, I'd argue for
keeping CREATE CONVERSION. But the performance headaches would be
substantial, and there aren't new encodings coming down the pike often
enough to justify the work involved, so I don't see us ever doing CREATE
ENCODING; and that means that CREATE CONVERSION is of little value.
I'd kind of like to see this go just because having catalog accesses
involved in encoding conversion setup is messy and fragile.
regards, tom lane