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