Noah Misch <n...@leadboat.com> writes: > On Wed, Jan 06, 2016 at 11:56:14PM -0500, Tom Lane wrote: >> 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.
> Per the 3ac1ac58c log message, "CREATE OPERATOR CLASS only allows one default > opclass per datatype regardless of schemas." That had been true since day one > for CREATE OPERATOR CLASS. It doesn't hold for conversions today, and that's > a crucial difference between that commit and this proposal. Well, the state of affairs is slightly different, but that doesn't mean it's not equally broken. What I took away from the default-opclass fiasco is that search-path-based lookup is a good idea only when you are looking up something *by name*, so that the user can resolve any ambiguity by schema-qualifying that name. Searches that aren't based on a user-specified name shouldn't depend on search_path. This is important because there are multiple conflicting concerns when you choose a search_path setting, and you may not want to allow any particular search to force your hand on what you put where in your search path. If, for example, you don't really want to put "public" on the front of your search path, the current code gives you no way to select a conversion that's in "public". If we need to cater for alternative conversions, my preference would be a GUC or some other kind of setting that allows selecting a client I/O conversion by name, whether it is "default" or not. But given the lack of apparent demand, I don't really want to design and implement such a feature right now. 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