Re: 2024-05-09 release announcement draft

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: 2024-05-09 release announcement draft
Date: 2024-05-07 02:58:49
Message-ID: cc6b3329-b054-4902-b967-3129a90b1db6@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/6/24 5:08 PM, David Rowley wrote:
> On Tue, 7 May 2024 at 05:44, Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
>> Please provide feedback no later (and preferably sooner) than 2024-05-09
>> 12:00 UTC.
>
> Thanks for the draft. Here's some feedback.
>
>> * Fix [`INSERT`](https://www.postgresql.org/docs/current/sql-insert.html) from
>> multiple [`VALUES`](https://www.postgresql.org/docs/current/sql-values.html)
>> rows into a target column that is a domain over an array or composite type.
>> including requiring the [SELECT privilege](https://www.postgresql.org/docs/current/sql-grant.html)
>> on the target table when using [`MERGE`](https://www.postgresql.org/docs/current/sql-merge.html)
>> when using `MERGE ... DO NOTHING`.
>
> Something looks wrong with the above. Are two separate items merged
> into one? 52898c63e and a3f5d2056?

Ugh, I see what happened. I was originally planning to combine them, and
then had one be the lede, then the other. Given I ended up consolidating
quite a bit, I'll just have them each stand on their own. I'll fix this
in the next draft (which I'll upload on my Tuesday).

>> * Fix confusion for SQL-language procedures that returns a single composite-type
>> column.
>
> Should "returns" be singular here?

Fixed.

>> * Throw an error if an index is accessed while it is being reindexed.
>
> I know you want to keep these short and I understand the above is the
> same wording from release notes, but these words sound like a terrible
> oversite that we allow any concurrent query to still use the table
> while a reindex is in progress.

Yeah, I was not happy with this one at all.

Maybe we should give more detail
> there so people don't think we made such a silly mistake. The release
> note version I think does have enough words to allow the reader to
> understand that the mistake is more complex. Maybe we could add
> something here to make it sound like less of an embarrassing mistake?

Based on this, I'd vote to just remove it from the release announcement.

Jonathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2024-05-07 03:02:27 Re: 2024-05-09 release announcement draft,2024-05-09 release announcement draft
Previous Message Michael Paquier 2024-05-07 02:50:05 Re: Use pgstat_kind_infos to read fixed shared stats structs