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