Re: security_definer_search_path GUC - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: security_definer_search_path GUC
Date
Msg-id CAL9smLBj4YjXWxf4Ngz3e7WhwdGX0B0WkH8n_he8gB9KEkr0BQ@mail.gmail.com
Whole thread Raw
In response to Re: security_definer_search_path GUC  ("Joel Jacobson" <joel@compiler.org>)
Responses Re: security_definer_search_path GUC  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: security_definer_search_path GUC  ("Joel Jacobson" <joel@compiler.org>)
List 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 by date:

Previous
From: John Naylor
Date:
Subject: speed up verifying UTF-8
Next
From: Alvaro Herrera
Date:
Subject: Re: pg_stat_progress_create_index vs. parallel index builds