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 <br...@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 + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
