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

From: Nicolas Ross <nicolas(at)cybercat(dot)ca>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #10500: Cannot restore from a dump when some function is used in public shcema
Date: 2014-06-02 19:39:58
Message-ID: 538CD30E.3030005@cybercat.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tom Lane a écrit :

>> 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
Oh !

Thanks for pointing that out. I modified my function definition and now
my restore can complete without an error.

Regards,

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Greg Stark 2014-06-03 00:36:40 Re: BUG #10432: failed to re-find parent key in index
Previous Message Andres Freund 2014-06-02 18:48:43 Re: uninterruptable loop: concurrent delete in progress within table