From: | Dominique Devienne <ddevienne(at)gmail(dot)com> |
---|---|
To: | Wolfgang Walther <walther(at)technowledgy(dot)de> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: DROP OWNED BY fails with #53200: ERROR: out of shared memory |
Date: | 2022-01-11 13:33:45 |
Message-ID: | CAFCRh--GEFtZqK3oN4Gsq8u62oBS=EEtaxpMNmW_6w0_hcEAHw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Jan 11, 2022 at 12:47 PM Wolfgang Walther <walther(at)technowledgy(dot)de>
wrote:
> Dominique Devienne:
> > I wish for DB-specific ROLEs BTW...
>
> Same here. That would be so useful.
>
In fact, in my case, I also want something even narrower than that,
which are SCHEMA specific ROLEs. ROLEs tied to a given schema,
implicitly DROP'ed when their "owner" SCHEMA is DROP'ed , and which
can only take GRANTs/privileges on objects from it owner schema.
I'm not saying CLUSTER-wide ROLEs are not useful. They are, mostly for
LOGIN USERs IMHO.
But for NOLOGIN ROLEs used to group permissions, often in a single DB, or
even a single SCHEMA like in my case,
the fact ROLEs are CLUSTER-wide is problematic for the naming. FWIW. --DD
PS: I've read the note that DB-specific ROLEs kinda exists, but since the
doc explicitly mentions to avoid them,
I don't use them. And in case, as I wrote above, SCHEMA-correlated
ROLEs is what I really would like to use.
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2022-01-11 14:18:11 | Re: plpgsql function problem whith creating temp table - not correctly using search_path ? |
Previous Message | Amit Kapila | 2022-01-11 13:28:19 | Re: [Ext:] Re: Stream Replication not working |