Noah Misch <n...@leadboat.com> writes:
> 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.
The built-in conversions are very intentionally not pinned. So to my
mind, the supported way to replace one is to drop it and create your own.
The way you describe works only if an appropriate search path is installed
at the time a new session activates its client encoding conversions. TBH,
I have no idea whether we apply (for example) "ALTER ROLE SET search_path"
before that happens; but even if we do, there's no real guarantee that it
wouldn't change. We publish no documentation about the order of startup
actions. Moreover past attempts at defining dependencies between GUC
settings have been spectacular failures, so I really don't want to go
there in this context.
It would only be important to be able to do it like that if different
users of the same database had conflicting ideas about what was the
correct conversion between client and database encodings. I submit
that that's somewhere around epsilon probability, considering we have
not even heard of anyone replacing the system conversions at all.
(Adding conversions we don't supply is, of course, orthogonal to this.)
Moreover, we have precedent both for this approach being a bad idea
and for us changing it without many complaints. We used to have
search-path-dependent lookup of default index operator classes.
We found out that that was a bad idea and got rid of it, cf commit
3ac1ac58c. This situation looks much the same to me.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
