On Thu, Oct 16, 2014 at 3:34 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Thu, Oct 16, 2014 at 3:09 PM, Stephen Frost <sfr...@snowman.net> wrote: >> > * Robert Haas (robertmh...@gmail.com) wrote: >> >> Ah, good point. Using ALTER ROLE is better. Maybe we should do ALTER >> >> ROLE .. [ ADD | DROP ] CAPABILITY x. That would still require making >> >> CAPABILITY a keyword, but it could be unreserved. >> > >> > That works for me- would we change the existing role attributes to be >> > configurable this way and change everything over to using an int64 in >> > the catalog? Unless I'm having trouble counting, I think that would >> > actually result in the pg_authid catalog not changing in size at all >> > while giving us the ability to add these capabilities and something like >> > 50 others if we had cause to. >> >> I definitely think we should support the new syntax for the existing >> attributes. > > Ok. > >> I could go either way on whether to change the catalog >> storage for the existing attributes. Some people might prefer to >> avoid the backward compatibility break, and I can see that argument. > > There's really two issues when it comes to backwards compatibility here- > the catalog representation and the syntax. > > My feeling is basically this- either we make a clean break to the new > syntax and catalog representation, or we just use the same approach the > existing attriubtes use. Long term, I think your proposed syntax and an > int64 representation is better but it'll mean a lot of client code that > has to change. I don't really like the idea of changing the syntax but > not the representation, nor am I thrilled with the idea of supporting > both syntaxes, and changing the syntax without changing the > representation just doesn't make sense to me as I think we'd end up > wanting to change it later, making clients have to update their code > twice.
I don't see any reason why it has to be both or neither. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
