* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Robert Haas 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.
>
> I was thinking we would change the catalogs and implement the new syntax
> for new and old settings, but also keep the old syntax working as a
> backward compatibility measure. I don't see what's so terrible about
> continuing to support the old syntax; we do that in COPY and EXPLAIN,
> for example.
It just complicates things and I'm not sure there's much benefit to it.
Clients are going to need to be updated to support the new attributes
anyway, and if the new attributes can only be used through the new
syntax, well, I don't know why they'd want to deal with the old syntax
too.
That said, I don't feel very strongly about that position, so if you and
Robert (and others on the thread) agree that's the right approach then
I'll see about getting it done.
Thanks!
Stephen