From: | Jeremy Cowgar <jeremy(at)cowgar(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14649: Function Namespace Resolution Bug |
Date: | 2017-05-12 19:16:49 |
Message-ID: | 1F6612EB-9846-478A-A4C5-608439B05574@cowgar.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I didn’t realize that pg_dump alters the search path. Couldn’t pg_dump simply append the default search path to the end of it’s custom setting? That should solve the problem as well? We have not changed our search path and it seems the default is “$user”, public.
Jeremy Cowgar
> On May 12, 2017, at 2:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Jeremy Cowgar <jeremy(at)cowgar(dot)com> writes:
>> Why does it find the initial function just fine in the public namespace, but the method it calls it can not find, which is in the same namespace as the calling function?
>
> pg_dump is smart enough to schema-qualify that one. If you look at
> the actual dump output for the table, it looks like
>
> SET search_path = g, pg_catalog;
> ...
> CREATE TABLE people (
> id integer NOT NULL,
> name character varying(50) NOT NULL,
> CONSTRAINT people_name_check CHECK (public.has_content((name)::text))
> );
>
> However, editing the body text of your function is beyond pg_dump's
> competence.
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-05-12 20:10:51 | Re: BUG #14649: Function Namespace Resolution Bug |
Previous Message | Tom Lane | 2017-05-12 18:50:50 | Re: BUG #14649: Function Namespace Resolution Bug |