Re: security_definer_search_path GUC

Поиск
Список
Период
Сортировка
От Joel Jacobson
Тема Re: security_definer_search_path GUC
Дата
Msg-id 4982318b-8a1b-47c8-aedd-6ece30fe0375@www.fastmail.com
обсуждение исходный текст
Ответ на Re: security_definer_search_path GUC  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: security_definer_search_path GUC  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: security_definer_search_path GUC  (Marko Tiikkaja <marko@joh.to>)
Список pgsql-hackers
On Thu, Jun 3, 2021, at 00:55, Marko Tiikkaja wrote:
On Wed, Jun 2, 2021 at 11:32 PM Joel Jacobson <joel@compiler.org> wrote:
But if running a recent PostgreSQL version, with support for extensions, I think an even cleaner solution
would be to package such compatibility versions in a "compat" extension, that would just install them into the public schema.

Writing, verifying and shipping extension upgrade scripts is not pleasant. 

I agree. Thanks for acknowledging this problem.

I'm experimenting with an idea that I hope can simplify the "verifying" part of the problem.
hope to have something to show you all soon. 

I'd much prefer something that's integrated to the workflow I already have.

Fair point. I guess also the initial switching cost of changing workflow is quite high and difficult to motivate. So even if extensions ergonomics are improved, many existing users will not migrate their workflows anyway due to this.

 
And if you wonder what functions in public come from the compat extension, you can use use \dx+.

They still show up everywhere when looking at "public".  So this is only slightly better, and a maintenance burden.

Good point. I find this annoying as well sometimes.

It's easy to get a list of all objects for an extension, via \dx+

But it's hard to see what objects in a schema, that are provided by different extensions, via e.g. \df public.*

What about adding a new "Extension" column next to "Schema" to the relevant commands, such as \df?

/Joel

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

Предыдущее
От: Masahiro Ikeda
Дата:
Сообщение: Re: Transactions involving multiple postgres foreign servers, take 2
Следующее
От: David Rowley
Дата:
Сообщение: Re: Fixup some appendStringInfo and appendPQExpBuffer calls