Re: BUG #14649: Function Namespace Resolution Bug

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

In response to

Responses

Browse pgsql-bugs by date

  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