Re: security_definer_search_path GUC

Поиск
Список
Период
Сортировка
От Marko Tiikkaja
Тема Re: security_definer_search_path GUC
Дата
Msg-id CAL9smLBj4YjXWxf4Ngz3e7WhwdGX0B0WkH8n_he8gB9KEkr0BQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: security_definer_search_path GUC  ("Joel Jacobson" <joel@compiler.org>)
Ответы Re: security_definer_search_path GUC  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: security_definer_search_path GUC  ("Joel Jacobson" <joel@compiler.org>)
Список pgsql-hackers
On Wed, Jun 2, 2021 at 3:46 PM Joel Jacobson <joel@compiler.org> wrote:
If a database object is to be accessed unqualified by all users, isn't the 'public' schema a perfect fit for it? How will it be helpful to create different database objects in different schemas, if also adding all such schemas to the search_path so they can be accessed unqualified? In such a scenario you risk unintentionally creating conflicting objects, and whatever schema happened to be first in the search_path will be resolved. Seems insecure and messy to me.

Heh.  This is actually exactly what I wanted to do.

The use case is: version upgrades.  I want to be able to have a search_path of something like 'pg_catalog, compat, public'.  That way we can provide compatibility versions of newer functions in the "compat" schema, which get taken over by pg_catalog when running on a newer version.  That way all the compatibility crap is clearly separated from the stuff that should be in "public".


.m

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

Предыдущее
От: John Naylor
Дата:
Сообщение: speed up verifying UTF-8
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_stat_progress_create_index vs. parallel index builds