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