From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PG 18 release notes draft committed |
Date: | 2025-05-20 12:28:18 |
Message-ID: | aCx1YqtuPYGbYuh-@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 13, 2025 at 08:05:24AM +0200, Laurenz Albe wrote:
> On Mon, 2025-05-12 at 20:27 -0700, David G. Johnston wrote:
> > Should all columns removed from system views and/or catalogs be listed in
> > “Migration” or is there some filtering criteria? There are at minimum quite
> > a few statistics related ones we’ve dropped that only appear in the Changes
> > section (e.g., pg_stat_io, pg_stat_wal).
>
> I am not sure.
>
> On the one hand, the catalogs don't promise to be a stable API, so there
> would be no need to enumerate such changes as compatibility breaks.
> The "Migration" section also doesn't list changes to the exported
> PostgreSQL functins, which has bitten me as extension developer several
> times.
>
> On the other hand, the catalogs are described in the documentation, which
> gives them more exposure, and it doesn't seem unreasonable to document
> breaking changes as well.
>
> Do you have an idea how many changes there are? If there are not too many,
> and somebody is willing to do the work, I wouldn't be against it.
First, I apologize for the delay in my replying --- I was on vacation
last week.
Second, let me explain the criteria I use for table changes, and then we
can discuss if the criteria is correct, and whether I followed the
criteria accurately for PG 18.
So, there are system views and system tables. Most system views are
important to users, because we created them mostly for user consumption,
while system tables might or might not hold useful information for
users.
Second, we have three possible changes --- column addition, column
renaming, and column removal. And third, we can list the changes in the
incompatibility section, or in the main release notes.
So, for column additions, I would never list them in the incompatibility
section, though it could break SELECT *. For renames and deletes, they
would normally appear in the incompatibility section, unless they are
system tables that do not normally hold user-helpful information, in
which case I might list it in the main section, or not at all.
I believe I followed that criteria for PG 18. There might be a few
cases in PG 18 where columns used for monitoring were renamed or deleted
because they were replaced, and I felt it was too complex to list them
in the incompatibility section because there were new features mixed
into the process so I listed them in the main section. I thought that
was the proper balance.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2025-05-20 12:43:16 | Re: strange perf regression with data checksums |
Previous Message | Bruce Momjian | 2025-05-20 12:01:47 | Re: PG 18 release notes draft committed |