On 1/6/17 7:21 PM, Bruce Momjian wrote:
> 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.
Except in this case we can provide a clean new API without gratuitously
breaking the old one.
I absolutely do agree that we have to have a way of making incompatible
changes from time to time (as I've been arguing over and over in the
plpgsql2 thread). I also think a one-size-fits-all approach to when a
break is allowed would be good. That said, the change to
pg_stat_activity caused a lot of needless user pain, and this one will
as well.
What makes this even more frustrating (to me at least) is that the
attitude that's been demonstrated around plpgsql is that there can
absolutely NEVER be a compatibility break of any kind.
So part of the project thinks it's perfectly OK to just break things
without any warning or support, while another part of the project
adamantly refuses any kind of a break at all, even what's breaking has
never officially been supported.
I don't think that dichotomy is good for the community or for our users.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)
