Re: Additional role attributes && superuser review

On Thu, Oct 16, 2014 at 3:34 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> On Thu, Oct 16, 2014 at 3:09 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> > * Robert Haas (robertmhaas(at)gmail(dot)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