Stephen Frost wrote: > Alvaro, > > * Alvaro Herrera (alvhe...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers