* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Oct 16, 2014 at 3:34 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > 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.
My reasoning on that is that either breaks existing clients and so
they'll have to update and if we're going to force that then we might as
well go whole-hog and get it over with once.
If my assumption is incorrect and we don't think changes to the catalog
representation will break existing clients then I withdraw the argument
that they should be done together.
For the syntax piece of it, my feeling is that all these role attributes
should be handled the same way. There's three ways to address that-
support them using the existing syntax, change to a new syntax and only
support that, or have two different syntaxes. I don't like the idea
that these new attributes will be supported with one syntax but the old
attributes would be supported with a different syntax.
If we think it's too much to change in one release, I could see changing
the catalog representation and then providing the new syntax while
supporting the old syntax as deprecated, but we do have a pretty bad
history of such changes and any maintained client should be getting
updated for the new role attributes anyway..
Thanks!
Stephen
