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.
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 |