| 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: | Whole Thread | Raw Message | 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 |