On 2018-08-21 16:39:18 +0200, Lukas Eder wrote:
> On Tue, Aug 21, 2018 at 4:28 PM Andres Freund <andres@anarazel.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
