Re: BUG #15344: pg_proc.proisagg was removed incompatibly in PostgreSQL 11

From: Andres Freund <andres(at)anarazel(dot)de>
To: Lukas Eder <lukas(dot)eder(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15344: pg_proc.proisagg was removed incompatibly in PostgreSQL 11
Date: 2018-08-21 14:45:48
Message-ID: 20180821144548.nxx2xx4hr2ujt4qw@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2018-08-21 16:39:18 +0200, Lukas Eder wrote:
> On Tue, Aug 21, 2018 at 4:28 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> > Hi,
> >
> > On 2018-08-21 14:23:45 +0000, PG Bug reporting form wrote:
> > > When comparing the current version (10) [1] and the developer version
> > (11)
> > > [2] of the pg_proc documentation, then it can be seen that the
> > > pg_proc.proisagg column was removed backwards incompatibly. The
> > > documentation states for [1]:
> >
> > Please note that the pg_catalog.* tables (and views) are *NOT* intended
> > to backwards compatible between major versions. We change them in ways
> > backward incompatible all the time.
> >
>
> The pg_catalog tables do seem to be the only way to reverse engineer some
> more sophisticated things in the database.

Yes, there's some things that aren't represented in a standardized way
in information_schema.*. If that's the case it's good for tool vendors
to pipe up and ask for something intended to be externally visible.

> I imagine that this is being
> done by tool vendors like myself (jOOQ) quite a bit. And there are tons of
> Stack Overflow answers that show how to query the pg_catalog tables, all of
> them risking to be outdated between major versions.

People doing bad things on stackoverflow isn't very convincing.... ;)

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

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Mark Lai 2018-08-21 14:46:52 Re: BUG #15333: pg_dump error on large table -- "pg_dump: could not stat file...Unknown error"
Previous Message Lukas Eder 2018-08-21 14:39:18 Re: BUG #15344: pg_proc.proisagg was removed incompatibly in PostgreSQL 11