Re: PG 18 relnotes and RC1

On 9/18/25 1:38 PM, Robert Haas wrote:
> On Thu, Sep 18, 2025 at 12:59 PM Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
>>> I like Nathan's version better. I suggest we go with that one.
>>
>> Why? This seems arbitrary without more details.
>>
>> I’ve spent the past several weeks staring at the release notes, talking to users, and putting together a presentation on it that was delivered last night, also culminating in the press release. I put a lot of effort into researching what to highlight up top, which is augmented in the release details itself. Additionally I started from what Nathan had and tweaked a few items.
>
> That seems completely backwards to me.

Glad to hear I've been doing my job backwards for years ;) That said, I
am always willing to learn how to improve the process.

> We should go with the version
> that was submitted weeks ago and upon which people have had the
> opportunity to comment unless you can justify each change that you now
> want to make at the last minute.

Happy to justify all of this. First, with a few more weeks, we have more
data points on how things are going to be used, so it's OK to make it at
this opint.
> Why for example should we drop
> mentioning the ability to return OLD.* and NEW.* in favor of mentioned
> UUIDv7?

UUIDv7 was in the original one, and it's been carried forward. The
change was I explicitly brought in the function name and the link to it.

> I'd argue that the former is more important than the latter,
> and I don't see how you can argue otherwise except by appealing to the
> research you've done over the last several weeks.

UUIDs are more used way more than RETURNING statements. For example,
last night at the PG18 meetup, everyone's hand went up for using UUIDs,
and no one's hand went up for RETURNING. I did demo that feature last
night and it was pretty cool, and many ORMs use RETURNING on DML
statements to return the info and it's a neat feature. I'm not opposed
to including it in there, but I didn't include it in this draft because
it comes from something that doesn't impact as many users.

That said, if people feel strongly about it, I'm OK to add it back.

> But none of us have
> access to that or got a vote in it. These things ought to be decided
> by consensus. If you want your research to feed into the building of
> that consensus, you need to do it and present it earlier.

I posted a patch now; there's still a few days before this is finalized,
and we can iterate on it. The press release was also posted a few weeks
back with time for people to comment on it, too.

This is a task I've helped on every year for nearly a decade and there
have been limited complaints, other than a healthy discussion on what
features should be in the list. For personal reasons I didn't get to
this specific part as early as usual, and given my history of the work
I've done on the release, I would have expected a bit more empathy
towards pulling this together. And of course, I'm always open to
well-stated opinions on what to do.

> For example,
> if you want to present survey results, I think that's a great way to
> help decide these kinds of things, but then other people should have
> the right to present their own survey results and so on in that
> conversation too.

That's great - your original comment didn't do that though, and I could
have better stated why I put together the list as is.

I will go look at Nathan's original patch one more time at the delta and
post a revision shortly.

Thanks,

Jonathan