Andres,
* Andres Freund (andres@anarazel.de) wrote:
> On January 12, 2017 10:50:18 AM PST, Stephen Frost <sfrost@snowman.net> wrote:
> >* Andres Freund (andres@anarazel.de) wrote:
> >> On 2017-01-12 13:40:50 -0500, Stephen Frost wrote:
> >> > * Jim Nasby (Jim.Nasby@BlueTreble.com) wrote:
> >> > > The way I see it, either one person can spend an hour or whatever
> >> > > creating an extension once, or every postgres install that's
> >using
> >> > > any of these functions now has yet another hurdle to upgrading.
> >> >
> >> > I just don't buy this argument, at all. These functions names are
> >> > certainly not the only things we're changing with PG10 and serious
> >> > monitoring/backup/administration tools are almost certainly going
> >to
> >> > have quite a bit to adjust to with the new release, and that isn't
> >news
> >> > to anyone who works with PG.
> >>
> >> By that argument we can just do arbitrary backward incompat changes.
> >We
> >> should aspire to be better than we've been in the past, not use that
> >> past as an excuse for not even trying.
> >
> >When they're changes that are primairly going to affect
> >monitoring/backup/administration tools, yes, I do think we can make
> >just
> >about arbitrary backward-incompatible changes.
> >
> >As Robert mentioned, and I agree with, changing things which will
> >impact
> >regular application usage of PG is a different story and one we should
> >be more cautious about.
>
> I find it very hard to understand the justification for that, besides that it's strengthening external projects
providingmonitoring, backup, etc in a compatible way.
That might be understandable if these were entirely arbitrary changes
(which isn't actually what I'm talking about above), but they aren't.
These changes aren't being made just for the sake of making them and are
not entirely arbitrary, as I've already pointed out up-thread.
The point I was making above is that the only reason to not make such
changes is if they really are entirely arbitrary, but I don't think
we'd even be having this discussion if that was the case or that we'd
be split about the question. We already moved forward with the real
change here- pg_xlog -> pg_wal, it really astounds me that we're having
to argue about what is primairly just clean-up from that change, at
least in my view.
Also, frankly, I don't agree with the notion that this is seriously
going to "strengthen" external projects any more than the regular set of
changes that we're making as we move forward. Changing these functions
certainly isn't likely to change pgbackrest or barman or check_postgres
uptake any more than the pg_xlog -> pg_wal rename is going to. Maybe if
we *reverted* that change and then didn't make any other changes then
various hand-written tools would be able to work with PG10 without being
changed, but we might as well call it PG 9.6.2 then.
Thanks!
Stephen