Re: security_definer_search_path GUC - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: security_definer_search_path GUC
Date
Msg-id faa3397f-3aea-4b40-838b-56d63a64c41a@www.fastmail.com
Whole thread Raw
In response to Re: security_definer_search_path GUC  (Marko Tiikkaja <marko@joh.to>)
Responses Re: security_definer_search_path GUC
List pgsql-hackers
On Wed, Jun 2, 2021, at 18:36, Marko Tiikkaja wrote:
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".

That's a neat trick, probably the best solution in a really old PostgreSQL version, before we had extensions.

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.

Then, when upgrading, you would just not install the compat extension.

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

/Joel

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: make world and install-world without docs
Next
From: Alvaro Herrera
Date:
Subject: Re: pg_stat_progress_create_index vs. parallel index builds