From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | nicolas(at)cybercat(dot)ca |
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 18:11:09 |
Message-ID: | 17970.1401732669@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
nicolas(at)cybercat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-06-02 18:39:22 | Re: uninterruptable loop: concurrent delete in progress within table |
Previous Message | Andres Freund | 2014-06-02 17:40:07 | Re: BUG #10432: failed to re-find parent key in index |