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