Re: [BUGS] BUG #14649: Function Namespace Resolution Bug

Поиск
Список
Период
Сортировка
От Jeremy Cowgar
Тема Re: [BUGS] BUG #14649: Function Namespace Resolution Bug
Дата
Msg-id C85A4615-B255-4D73-B0E2-774980C542A8@cowgar.com
обсуждение исходный текст
Ответ на Re: [BUGS] BUG #14649: Function Namespace Resolution Bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [BUGS] BUG #14649: Function Namespace Resolution Bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Why does it find the initial function just fine in the public namespace, but the method it calls it can not find, which
isin the same namespace as the calling function? 

Jeremy Cowgar

> On May 12, 2017, at 2:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> jeremy@cowgar.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



--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [BUGS] BUG #14650: pg_dump -c fails when 'public' schema doesn't exist
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [BUGS] BUG #14649: Function Namespace Resolution Bug