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

  1. Make contrib/unaccent's unaccent() function work when not in search path.

  2. Avoid unnecessary use of pg_strcasecmp for already-downcased identifiers.