Re: Additional role attributes && superuser review

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

In response to

Responses

Browse pgsql-hackers by date

  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