On Wed, Jan 4, 2017 at 09:38:42AM -0500, Stephen Frost wrote:
> > I think we've been far to cavalier lately about unnecessarily breaking
> > admin and monitoring tools. There's been pg_stat_activity backward
> > incompat changes in most of the last releases. It's a *PAIN* to develop
> > monitoring / admin tools that work with a number of releases. It's fine
> > to cause that pain if there's some considerable benefit (e.g. not
> > triggering data loss seems like a case for that, as imo is unifying
> > configuration), but I don't see how that justifying breaking things
> > gratuitously. Just renaming well known functions for a minor bit of
> > cleanliness seems not to survive a cost/benefit analysis.
>
> I agree that we have been breaking monitoring tools on the regular for a
> while as we continue to add capabilities and improve things, which is
> part of the reason that I don't see this particular break as a very big
> deal- serious monitoring tools are going to need to be updated anyway.
>
> I don't see that changing any time soon either- we are woefully far
> behind in this area compared to other databases and we should be trying
> to encourage people to continue improving these areas, not making things
> unnecessairly difficult by requiring backwards compatibility hacks.
I agree. I know these changes are painful, and I will take
responsibility for perhaps the most cavalier breakage of
pg_stat_statements in renaming column procpid to pid. (I still stand
behind that change.)
As painful as these breakages are *at* the time of the breakage,
long-term, it keeps our user API clean. Frankly, because changes are
reviewed by so many people, we don't normally make dumb API mistakes
that require changes --- rather new features or complex interactions
require user API changes. We often feel we have too many users to make
the change, but every few years we double our user base and all those
new users see a nice clean API that previous users had to adjust to.
If we don't make changes like this, our API becomes nonintuitive very
quickly, and let's face it, we expose a lot of internal interfaces to
our users, so clarity is extra important.
I don't think anyone is arguing that these API breakages are cost-free,
but I think long-term, the costs are minor compared to the clean API we
provide to users.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
