From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Additional role attributes && superuser review |
Date: | 2015-03-02 19:21:32 |
Message-ID: | 20150302192132.GD3291@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost wrote:
> Alvaro,
>
> * Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> > That being so, I would consider the idea that the NO bit is a separate
> > word rather than run together with the actual privilege name. And given
> > that CREATE has all the options default to "NO", there is no need to
> > have these options at all in CREATE, is there?
>
> That's a good point, except that INHERIT is actually on by default, and
> LOGIN defaults to 'on' if you use CREATE USER, and 'off' if you use
> CREATE ROLE. If they were actually all 'no' by default then this
> simplication would work but it's not and therefore I don't think we want
> to have some which are allowed at CREATE time with 'on' and some with
> 'off' depending on whatever the default is. Today, you can write a
> script to easily duplicate an existing role by just looking at what is
> on and off and using X and NOX. This approach would require that script
> to know what's valid at CREATE time and what isn't.
All true.
> > where privilege can be:
> > SUPERUSER | CREATEDB | CREATEROLE
> > | CREATEUSER | INHERIT | LOGIN
> > | REPLICATION | EXCLUSIVE_BACKUP | ...
> > and option can be:
> > CONNECTION LIMIT connlimit
> > | [ ENCRYPTED | UNENCRYPTED ] PASSWORD 'password'
> > | VALID UNTIL 'timestamp'
>
> With the 'NO' distinct, as discussed above, it seems like we should be
> able to support this.. I certainly like it more too.
Great.
> Certainly, and I like where you're going with this, just seems like
> there's a couple wrinkles to deal with.
Yeah.
Let's go with the "NO_" prefix then ... that seems better to me than no
separator.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-03-02 19:29:42 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0 |
Previous Message | Heikki Linnakangas | 2015-03-02 19:20:43 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0 |