Re: security_definer_search_path GUC

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Joel Jacobson <joel(at)compiler(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: security_definer_search_path GUC
Date: 2021-06-07 21:22:36
Message-ID: CAKFQuwZF6n_LW0Ove1F6LFmoNR5Lh8yxG4OJL38EFjZDEFovHg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 7, 2021 at 2:09 PM David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> On Fri, Jun 4, 2021 at 9:03 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
>> pá 4. 6. 2021 v 17:43 odesílatel Joel Jacobson <joel(at)compiler(dot)org>
>> napsal:
>>
>>> Maybe this could work:
>>> CREATE SCHEMA schema_name UNQUALIFIED;
>>> Which would explicitly make all the objects created in the schema
>>> accessible unqualified, but also enforce there are no conflicts with other
>>> objects in existence in all unqualified schemas, upon the creation of new
>>> objects.
>>>
>>
>> Yes, it can work. I am not sure if "unqualified" is the best keyword, but
>> the idea is workable.
>>
>
> Sounds like a job for an event trigger listening to CREATE/ALTER schema.
>

Never mind...I got mixed up a bit on what this all is purporting to do. My
intent was to try and solve the problem with existing features (event
triggers) instead of inventing new ones, which is still desirable.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2021-06-07 21:26:27 Re: security_definer_search_path GUC
Previous Message David G. Johnston 2021-06-07 21:09:18 Re: security_definer_search_path GUC