From: | Lukas Eder <lukas(dot)eder(at)gmail(dot)com> |
---|---|
To: | andres(at)anarazel(dot)de |
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:39:18 |
Message-ID: | CAB4ELO7Eyw9VoUhKsmJXD_-_qTT1o_6VFbH4TENpvKvo_UjZXQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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. 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. These queries are
probably used by quite a few people in some home grown build tool, reverse
engineering tool, etc.
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?
Thanks,
Lukas
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-08-21 14:45:48 | Re: BUG #15344: pg_proc.proisagg was removed incompatibly in PostgreSQL 11 |
Previous Message | Andres Freund | 2018-08-21 14:28:21 | Re: BUG #15344: pg_proc.proisagg was removed incompatibly in PostgreSQL 11 |