From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jeremy(at)cowgar(dot)com |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14649: Function Namespace Resolution Bug |
Date: | 2017-05-12 18:13:54 |
Message-ID: | 26979.1494612834@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
jeremy(at)cowgar(dot)com writes:
> In short, when a CHECK on a column in a different schema references a
> function in public that references another function in public implicitly,
> there is confusion. The workaround is to prefix the function calls with the
> schema.
I don't see any PG bug here. If you don't schema-qualify the function
reference, then it is dependent on the current search_path, and pg_dump/
pg_restore have their own ideas about how to set search_path. Even if
those two somehow magically intuited what search_path you're expecting,
this coding would still be fragile since some other user might use a
different search_path than you while accessing the table. The schema
qualification isn't a "workaround", it's just good coding practice.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | tureba | 2017-05-12 18:18:01 | BUG #14650: pg_dump -c fails when 'public' schema doesn't exist |
Previous Message | jeremy | 2017-05-12 17:40:59 | BUG #14649: Function Namespace Resolution Bug |