Re: unaccent(text) fails depending on search_path (WAS: pg_upgradefails saying function unaccent(text) doesn't exist)

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: unaccent(text) fails depending on search_path (WAS: pg_upgradefails saying function unaccent(text) doesn't exist)
Дата
Msg-id 20180907223247.GH28811@momjian.us
обсуждение исходный текст
Ответ на Re: unaccent(text) fails depending on search_path (WAS: pg_upgrade fails saying function unaccent(text) doesn't exist)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: unaccent(text) fails depending on search_path (WAS: pg_upgrade fails saying function unaccent(text) doesn't exist)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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 +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes
Следующее
От: Tom Lane
Дата:
Сообщение: StandbyAcquireAccessExclusiveLock doesn't necessarily