| From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
|---|---|
| To: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>, David Christensen <david+pg(at)pgguru(dot)net> |
| Subject: | Re: First draft of PG 19 release notes |
| Date: | 2026-05-12 14:57:57 |
| Message-ID: | CAAKRu_Yt7KyOp1bKo31VVGrqhfLJAW=mGo2d9HJWaQbLSHDY=w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, May 12, 2026 at 8:42 AM Greg Sabino Mullane <htamfids(at)gmail(dot)com> wrote:
>
> I can kind of understand why this did not make the cut:
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=41d69e6d
>
> (Add labels to help make psql's hidden queries more understandable)
>
> ... but I'm in favor (yes, somewhat selfishly to be honest) of listing all changes, no matter how small. Is there a written criteria or guidelines for these things? I think the bar is already low if we list things like "improved tab completion", TBH.
I agree that it is hard to know when advocating for our own features
makes sense on this thread. When another feature makes the list that
seems to have a less compelling case, it is tempting to jump in again.
But then, how do we know we are being objective and doing what is in
the best interest of the user reading the release notes?
For example, I upthread [1] suggested that users may want to know that
different WAL records would be produced because we've eliminated one
and incorporated their contents into another. While it is a
performance improvement, I mainly suggested it because an advanced
user examining WAL may be confused. Bruce noted that this was too
internal. I can see his point. But there are other things mentioned
that are as internal or more so. But arguing makes me feel like I'm
doing self-promotion. I've transitioned to only bringing up things
that I did that seem like they would be confusing to the user and they
would go to the release notes to check for, as opposed to bringing up
performance improvements.
However, for performance improvements, at some point the bar was
something that would encourage people to go through the effort of
upgrading to the latest version to get those improvements or to
migrate to Postgres when they previously may not have because a
performance related thing was holding them back. Things like improved
tab completion are probably not this kind of tipping point, so I think
that isn't the threshold anymore.
I would be interested in seeing a summary of where we landed in terms
of criteria for what should be in the release notes on this thread,
since it is split across many emails. I get the sense that we've
shifted it a bit based on discussion in this thread, and I can't quite
grasp the specifics. And people who replied early on but not after the
discussion led to changes may not be paying attention to the thread
anymore.
- Melanie
[1] https://www.postgresql.org/message-id/ad_6RBwUlRooQK-9%40momjian.us
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2026-05-12 15:30:22 | Re: Add psql tab completion support for FOR PORTION OF |
| Previous Message | Sami Imseih | 2026-05-12 14:50:18 | Re: Track skipped tables during autovacuum and autoanalyze |