Re: BUG #15344: pg_proc.proisagg was removed incompatibly inPostgreSQL 11 - Mailing list pgsql-bugs

On Tue, Aug 21, 2018 at 05:04:13PM +0200, Lukas Eder wrote:
> On Tue, Aug 21, 2018 at 4:45 PM Andres Freund <andres@anarazel.de> wrote:
>      > I understand that backwards compatibility is quite a bit of extra work,
>     but
>     > in cases like this particular one, the price to pay seems relatively low.
>     > Perhaps a new strategy could be to break things only if there is really
>     no
>     > other solution?
> 
>     I mean we don't break things willy-nilly already. And there's plenty
>     cases where we kept things around for backward compatibility. But
>     usually the problem is that that means you have to keep the shim around
>     forever. Even if better solutions have been around for many years,
>     there'll be complaints about removing them.  So IMO the backward compat
>     price for pg_catalog.* has to be low enough that there's essentially no
>     point in keeping it around forever, or so painful that it'd cost a lot
>     of people a lot.
> 
> 
> I agree that at some point, the price to pay is too high. But in this case, a
> boolean value has been replaced by an enumeration, so it would be really easy
> to maintain the boolean value as a computed column, right?

We realize we are breaking some things by changing any API.  The
question is whether the breakage is worth the cleaner API for users
going forward.

People regularly complain when we break APIs, and ask us to justify
every decision, which we are willing to do.  However, few people
complain when we keep old APIs around.  The big issue is that keeping
old APIs around has a much higher cost than the API breakage we do, in
most cases.  This is because API breakage is a big hurt for a few
people, but keeping around an old API is a small hurt for many, and for
a long duration.  So, you hear about the big hurts, but not about the
many small ones, but that doesn't mean we should ignore the small ones.

Anyone who has used an API that allows you to do things in
several old and new ways knows the cost of such API complexity, and the
server programming complexity of keeping old APIs working properly.

Being specific, we almost never change the library API (libpq), and we
rarely change the SQL API, though there are cases listed the major
release notes.  We often change the administrators API and system system
catalog contents, as you have seen.  These decisions are all related to
the ability of users to detect and adjust to API changes, the ability to
keep the old API active, and the number of users effected.

Telling us we broke an API and that we were wrong really doesn't tell us
anything --- we already knew we broke it, and suspected some people
would be disappointed.  You need to walk into that calculus and tell us
why our estimates were wrong.  However, most users just don't have the
level of Postgres knowledge to really argue such cases, even if we are
wrong.

We have also made the decision long ago that we would rather present a
clean API to future users than avoid reasonable breakage for current
users.  People who want that policy changed must get quite involved so
they can argue with the calculus we are already using.  There also might
be cases where our API breakage is too extreme and another relational
database product might be a better fit.

I am thinking I should create a wiki page explaining how we make API
breakage decisions so we don't need to re-litigate this each time.

-- 
  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 +