Re: BUG #10500: Cannot restore from a dump when some function is used in public shcema

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #10500: Cannot restore from a dump when some function is used in public shcema
Дата
Msg-id 17970.1401732669@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #10500: Cannot restore from a dump when some function is used in public shcema  (nicolas@cybercat.ca)
Ответы Re: BUG #10500: Cannot restore from a dump when some function is used in public shcema  (Nicolas Ross <nicolas@cybercat.ca>)
Список pgsql-bugs
nicolas@cybercat.ca writes:
> I narrow it down to this simple exemple. Here's a pg_dump in plain text of
> my test case :

> CREATE SCHEMA intranet;
> CREATE EXTENSION IF NOT EXISTS unaccent WITH SCHEMA public;
> SET search_path = public, pg_catalog;
> CREATE FUNCTION cyunaccent(character varying) RETURNS character varying
>     LANGUAGE sql IMMUTABLE
>     AS $_$ SELECT unaccent(lower($1)); $_$;

This function is unsafe on its face: it does not specify what schema to
find unaccent() in.  You need to either explicitly schema-qualify:

     SELECT public.unaccent(lower($1));

(for good measure it'd be wise to qualify lower() as well), or else attach
a "SET search_path" clause to the function definition.

It's arguable whether the search path sensitivity of such functions is
a feature or a bug.  But there are people depending on the fact that they
can change the search path and get different results, so it's unlikely
we'd change the definition now.

            regards, tom lane

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

Предыдущее
От: Nicolas Ross
Дата:
Сообщение: Re: BUG #10500: Cannot restore from a dump when some function is used in public shcema
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: uninterruptable loop: concurrent delete in progress within table