Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }
Дата
Msg-id 9f128dd2-c1b4-be7d-1655-400d7485f64a@joeconway.com
обсуждение исходный текст
Ответ на Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }
Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }
Список pgsql-hackers
On 9/25/23 11:30, Robert Haas wrote:
> I don't believe that people want to run their functions under a
> sanitized search_path that only includes system schemas. That might
> work for some people, but I think most people will define functions
> that call other functions that they themselves defined, or access
> tables that they themselves created. They will therefore need the
> search_path to include the schemas in which they created those
> objects.
Without diving into all the detailed nuances of this discussion, this 
particular paragraph made me wonder if at least part of the problem here 
is that the same search_path is used to find "things that I want to 
execute" (functions and operators) and "things I want to access" 
(tables, etc).

I think many folks would be well served by only having system schemas in 
the search_path for the former (augmented by explicit schema qualifying 
of one's own functions), but agree that almost no one wants that for the 
latter (needing to schema qualify every table reference).

Should there be a way to have a separate "execution" search_path?

-- 
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Why need a lock?
Следующее
От: Matthias van de Meent
Дата:
Сообщение: Re: Improving btree performance through specializing by key shape, take 2