Re: First draft of PG 17 release notes

Peter Geoghegan <pg@bowt.ie>

From: Peter Geoghegan <pg@bowt.ie>
To: Andres Freund <andres@anarazel.de>
Cc: Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.us>, David Rowley <dgrowleyml@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Melanie Plageman <melanieplageman@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-05-24T18:26:48Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Revert support for ALTER TABLE ... MERGE/SPLIT PARTITION(S) commands

  2. When creating materialized views, use REFRESH to load data.

  3. Revert temporal primary keys and foreign keys

  4. Avoid needless large memcpys in libpq socket writing

  5. Enhance nbtree ScalarArrayOp execution.

  6. Introduce a non-recursive JSON parser

  7. Combine freezing and pruning steps in VACUUM

  8. Allow SIGINT to cancel psql database reconnections.

  9. Provide API for streaming relation data.

  10. Add hash support functions and hash opclass for contrib/ltree.

  11. Pull up ANY-SUBLINK with the necessary lateral support.

  12. Read WAL directly from WAL buffers.

  13. Introduce the dynamic shared memory registry.

  14. Add macros for looping through a List without a ListCell.

  15. Support +/- infinity in the interval data type.

  16. Extend ALTER OPERATOR to allow setting more optimization attributes.

  17. Consider cheap startup paths in add_paths_to_append_rel

On Fri, May 24, 2024 at 1:50 PM Andres Freund <andres@anarazel.de> wrote:
> Bruce, just about everyone seems to disagree with your current approach. And
> not just this year, this has been a discussion in most if not all release note
> threads of the last few years.

+1.

> People, including me, *have* addressed your criteria, but you just waved those
> concerns away. It's hard to continue discussing criteria when it doesn't at
> all feel like a conversation.

At one point on this thread, Bruce said "I am particularly critical if
I start to wonder, "Why does the author _think_ I should care about
this?" because it feels like the author is writing for him/herself and
not the audience."

Whenever this sort of thing has come up in the past, and I pushed
back, Bruce seemed to respond along these lines: he seemed to suggest
that there was some kind of conflict of interests involved. This isn't
completely unreasonable, of course -- my motivations aren't wholly
irrelevant. But for the most part they're *not* very relevant, and
wouldn't be even if Bruce's worst suspicions were actually true. In
principle it shouldn't matter that I'm biased, if I happen to be
correct in some relevant sense.

Everybody has some kind of bias. Even if my bias in these matters was
a significant factor (which I tend to doubt), I don't think that it's
fair to suggest that it's self-serving or careerist. My bias was
probably present before I even began work on the feature in question.
I tend to work on things because I believe that they're important --
it's not the other way around (at least not to a significant degree).

> In the end, these are patches to the source code, I don't think you can just
> wave away widespread disagreement with your changes. That's not how we do
> postgres development.

In lots of cases (a large minority of cases) the problem isn't even
really with the emphasis of one type of item over another/the
inclusion or non-inclusion of some individual item. It's actually a
problem with the information being presented in the most useful way.

Often I've suggested what I believe to be a better wording on the
merits (usually less obscure and more accessible language), only to be
met with the same sort of resistance from Bruce. If I've put a huge
amount of work into the item (as is usually the case), then I think
that I am at least entitled to a fair hearing.

I don't expect Bruce to meet me halfway, or even for him to meet me a
quarter of the way -- somebody has to be empowered to say no here
(even to very senior community members). I just don't think that he
has seriously considered my feedback in this area over the years. Not
always, not consistently, but often enough for it to seem like a real
problem.

--
Peter Geoghegan