* Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Oct 16, 2014 at 3:34 PM, Stephen Frost <sfr...@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
signature.asc
Description: Digital signature