On Tue, Jan 05, 2016 at 01:46:51PM -0500, Tom Lane wrote:
> I do not see a lot of point in the namespacing of encoding conversions
> either. Does anyone really need or use search-path-dependent lookup of
> conversions?
I have not issued CREATE CONVERSION except to experiment, and I have never
worked in a database in which someone else had created one. Among PGXN
distributions, CREATE CONVERSION appears only in the pyrseas test suite. It
could be hard to track down testimony on real-world usage patterns, but I
envision two credible patterns. First, you could change the default search
path to "corrected_conversions, pg_catalog, $user, public" and inject fixed
versions of the system conversions. One could use that to backport commit
8d3e090. Second, you could add conversions we omit entirely, like UTF8 ->
MULE_INTERNAL. Dropping search-path-dependent lookup would remove the
supported way to fix system conversions.
> (If they do, it's probably broken anyway, since for example
> we do not trouble to re-identify the client encoding conversion functions
> when search_path changes.)
That's bad in principle, but I'll guess it's tolerable in practice. Switching
among implementations of a particular conversion might happen with O(weeks) or
longer period, like updating your system's iconv() conversion tables. I can't
easily envision one application switching between implementations over the
course of a session. (An application doing that today probably works around
the problem, perhaps with extra "SET client_encoding" calls.)