Re: PG 18 relnotes and RC1 - Mailing list pgsql-hackers

On 9/18/25 1:38 PM, Robert Haas wrote:
> On Thu, Sep 18, 2025 at 12:59 PM Jonathan S. Katz <jkatz@postgresql.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
presentationon it that was delivered last night, also culminating in the press release. I put a lot of effort into
researchingwhat to highlight up top, which is augmented in the release details itself. Additionally I started from what
Nathanhad 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