Re: First draft of PG 17 release notes
Peter Geoghegan <pg@bowt.ie>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Revert support for ALTER TABLE ... MERGE/SPLIT PARTITION(S) commands
- 3890d90c1508 18.0 cited
-
When creating materialized views, use REFRESH to load data.
- b4da732fd64e 17.0 cited
-
Revert temporal primary keys and foreign keys
- 8aee330af55d 17.0 cited
-
Avoid needless large memcpys in libpq socket writing
- c4ab7da60617 17.0 cited
-
Enhance nbtree ScalarArrayOp execution.
- 5bf748b86bc6 17.0 cited
-
Introduce a non-recursive JSON parser
- 3311ea86edc7 17.0 cited
-
Combine freezing and pruning steps in VACUUM
- 6dbb490261a6 17.0 cited
-
Allow SIGINT to cancel psql database reconnections.
- cafe1056558f 17.0 cited
-
Provide API for streaming relation data.
- b5a9b18cd0bc 17.0 cited
-
Add hash support functions and hash opclass for contrib/ltree.
- 485f0aa85995 17.0 cited
-
Pull up ANY-SUBLINK with the necessary lateral support.
- 9f133763961e 17.0 cited
-
Read WAL directly from WAL buffers.
- 91f2cae7a4e6 17.0 cited
-
Introduce the dynamic shared memory registry.
- 8b2bcf3f287c 17.0 cited
-
Add macros for looping through a List without a ListCell.
- 14dd0f27d7cd 17.0 cited
-
Support +/- infinity in the interval data type.
- 519fc1bd9e9d 17.0 cited
-
Extend ALTER OPERATOR to allow setting more optimization attributes.
- 2b5154beab79 17.0 cited
-
Consider cheap startup paths in add_paths_to_append_rel
- a8a968a8212e 17.0 cited
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