Re: unaccent(text) fails depending on search_path (WAS: pg_upgrade fails saying function unaccent(text) doesn't exist)
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Gunnlaugur Thor Briem <gunnlaugur@gmail.com>, Adrian Klaver <adrian.klaver@aklaver.com>, pgsql-hackers@lists.postgresql.org
Date: 2018-09-07T22:32:47Z
Lists: pgsql-hackers, pgsql-general
On Wed, Sep 5, 2018 at 06:37:00PM -0400, Tom Lane wrote:
> [ redirecting to pgsql-hackers ]
>
> I wrote:
> > Gunnlaugur Thor Briem <gunnlaugur@gmail.com> writes:
> >> SET search_path = "$user"; SELECT public.unaccent('foo');
> >> SET
> >> ERROR: text search dictionary "unaccent" does not exist
>
> > Meh. I think we need the attached, or something just about like it.
> >
> > It's barely possible that there's somebody out there who's relying on
> > setting the search path to allow choosing among multiple "unaccent"
> > dictionaries. But there are way more people whose functions are
> > broken due to the recent search-path-tightening changes.
>
> Here's a slightly more efficient version.
If we are going down this route, is there any thought of handling
earchdistance the same way?
https://www.postgresql.org/message-id/20180330205229.GS8476@momjian.us
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Commits
-
Make contrib/unaccent's unaccent() function work when not in search path.
- d4ab3962613f 9.4.20 landed
- c79b39fb1c5b 9.5.15 landed
- a54f5b187a4a 10.6 landed
- a5322ca10fa1 12.0 landed
- 594ee1ada5bc 9.6.11 landed
- 25ff97ba77cb 9.3.25 landed
- 23aad181f447 11.0 landed
-
Avoid unnecessary use of pg_strcasecmp for already-downcased identifiers.
- fb8697b31aae 11.0 cited