Thread: 2024-05-09 release announcement draft
Hi, Please find the draft of the 2024-05-09 release announcement. Please review for corrections and any omissions that should be called out as part of this release. Please provide feedback no later (and preferably sooner) than 2024-05-09 12:00 UTC. Thanks, Jonathan
Attachment
Op 5/6/24 om 19:44 schreef Jonathan S. Katz: > Hi, > > Please find the draft of the 2024-05-09 release announcement. 'procedures that returns' should be 'procedures that return'
On Tue, 7 May 2024 at 05:44, Jonathan S. Katz <jkatz@postgresql.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? > * Fix confusion for SQL-language procedures that returns a single composite-type > column. Should "returns" be singular here? > * 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. 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? David
Re: 2024-05-09 release announcement draft,2024-05-09 release announcement draft
From
Sutou Kouhei
Date:
Hi, In <779790c7-45d7-4010-9305-c3f9e6a60323@postgresql.org>,<779790c7-45d7-4010-9305-c3f9e6a60323@postgresql.org> "2024-05-09 release announcement draft,2024-05-09 release announcement draft" on Mon, 6 May 2024 13:44:05 -0400, "Jonathan S. Katz" <jkatz@postgresql.org> wrote: > * Added optimization for certain operations where an installation has thousands > of roles. Added -> Add > * [Follow @postgresql on Twitter](https://twitter.com/postgresql) Twitter -> X Thanks, -- kou
On 5/6/24 5:08 PM, David Rowley wrote: > On Tue, 7 May 2024 at 05:44, Jonathan S. Katz <jkatz@postgresql.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
Attachment
Re: 2024-05-09 release announcement draft,2024-05-09 release announcement draft
From
"Jonathan S. Katz"
Date:
On 5/6/24 5:36 PM, Sutou Kouhei wrote: > Hi, > > In <779790c7-45d7-4010-9305-c3f9e6a60323@postgresql.org>,<779790c7-45d7-4010-9305-c3f9e6a60323@postgresql.org> > "2024-05-09 release announcement draft,2024-05-09 release announcement draft" on Mon, 6 May 2024 13:44:05 -0400, > "Jonathan S. Katz" <jkatz@postgresql.org> wrote: > >> * Added optimization for certain operations where an installation has thousands >> of roles. > > Added -> > Add Fixed. >> * [Follow @postgresql on Twitter](https://twitter.com/postgresql) > > Twitter -> > X I think this one is less clear, from browsing around. I think "X/Twitter" is considered acceptable, and regardless the domain is still pointing to "Twitter". However, I'll go with the hybrid adjustment. Jonathan
Attachment
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 5/6/24 5:08 PM, David Rowley wrote:
>>> * Throw an error if an index is accessed while it is being reindexed.
>> 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.
+1. This is hardly a major bug fix --- it's just blocking off
something that people shouldn't be doing in the first place.
regards, tom lane
On Tue, 7 May 2024 at 14:58, Jonathan S. Katz <jkatz@postgresql.org> wrote: > >> * Throw an error if an index is accessed while it is being reindexed. > > > > Based on this, I'd vote to just remove it from the release announcement. I'd prefer that over leaving the wording the way it is. Looking at the test case in [1], it does not seem like a very likely thing for people to hit. It basically requires someone to be telling lies about a function's immutability. David [1] https://www.postgresql.org/message-id/18363-e3598a5a572d0699@postgresql.org
On 5/6/24 11:05 PM, David Rowley wrote: > On Tue, 7 May 2024 at 14:58, Jonathan S. Katz <jkatz@postgresql.org> wrote: >>>> * Throw an error if an index is accessed while it is being reindexed. >>> >> >> Based on this, I'd vote to just remove it from the release announcement. > > I'd prefer that over leaving the wording the way it is. Looking at > the test case in [1], it does not seem like a very likely thing for > people to hit. It basically requires someone to be telling lies about > a function's immutability. I opted for that; and it turned out the other fix was simple, so here's an updated draft. Jonathan
Attachment
On Tue, 7 May 2024 at 15:09, Jonathan S. Katz <jkatz@postgresql.org> wrote: > I opted for that; and it turned out the other fix was simple, so here's > an updated draft. Thanks > * 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. I know this is the same wording as Tom added in [1], I might just have failed to comprehend something, but if I strip out the links and try to make sense of "Fix INSERT from multiple VALUES rows into", I just can't figure out how to parse it. I'm pretty sure it means "Fix multiple-row VALUES clauses with INSERT statements when ...", but I'm not sure. > * Require 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`. I think the last line should just be "with `NO NOTHING`" David [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=7155cc4a60e7bfc837233b2dea2563a2edc673fd
David Rowley <dgrowleyml@gmail.com> writes:
> I know this is the same wording as Tom added in [1], I might just have
> failed to comprehend something, but if I strip out the links and try
> to make sense of "Fix INSERT from multiple VALUES rows into", I just
> can't figure out how to parse it. I'm pretty sure it means "Fix
> multiple-row VALUES clauses with INSERT statements when ...", but I'm
> not sure.
The problem happens in commands like
INSERT INTO tab VALUES (1,2), (3,4), ...
We treat this separately from the single-VALUES-row case for
efficiency reasons.
regards, tom lane
On Tue, 7 May 2024 at 15:48, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > David Rowley <dgrowleyml@gmail.com> writes: > > I know this is the same wording as Tom added in [1], I might just have > > failed to comprehend something, but if I strip out the links and try > > to make sense of "Fix INSERT from multiple VALUES rows into", I just > > can't figure out how to parse it. I'm pretty sure it means "Fix > > multiple-row VALUES clauses with INSERT statements when ...", but I'm > > not sure. > > The problem happens in commands like > INSERT INTO tab VALUES (1,2), (3,4), ... > We treat this separately from the single-VALUES-row case for > efficiency reasons. Yeah, I know about the multi-row VALUES. What I'm mostly struggling to parse is the "from" and the double plural of "VALUES" and "rows". Also, why is it "from" and not "with"? I get that "VALUES" is a keyword that happens to be plural, but try reading it out loud. Why not "Fix INSERT with multi-row VALUES clauses ..."? David
David Rowley <dgrowleyml@gmail.com> writes:
> Why not "Fix INSERT with multi-row VALUES clauses ..."?
To my mind, the VALUES clause is the data source for INSERT,
so "from" seems appropriate. I'm not going to argue hard
about it.
regards, tom lane
On Mon, May 06, 2024 at 11:09:24PM -0400, Jonathan S. Katz wrote: > * Avoid leaking a query result from [`psql`](https://www.postgresql.org/docs/current/app-psql.html) > after the query is cancelled. I'd delete this item about a psql-lifespan memory leak, because (a) it's so minor and (b) there are other reasonable readings of "leak" that would make the change look more important.
On 5/7/24 12:16 AM, Tom Lane wrote: > David Rowley <dgrowleyml@gmail.com> writes: >> Why not "Fix INSERT with multi-row VALUES clauses ..."? > > To my mind, the VALUES clause is the data source for INSERT, > so "from" seems appropriate. I'm not going to argue hard > about it. OK, so I've read through this a few times and have sufficiently confused myself. So, how about this: * Fix how [`INSERT`](https://www.postgresql.org/docs/current/sql-insert.html) handles 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. Thanks, Jonathan
Attachment
On Thu, 9 May 2024 at 04:17, Jonathan S. Katz <jkatz@postgresql.org> wrote: > * Fix how > [`INSERT`](https://www.postgresql.org/docs/current/sql-insert.html) > handles 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. Maybe it's only me who thinks the double plural of "VALUES rows" is hard to parse. If that's the case I'll just drop this as it's not that important. FWIW, I'd probably write: * Fix issue with [`INSERT`](https://www.postgresql.org/docs/current/sql-insert.html) with a multi-row [`VALUES`](https://www.postgresql.org/docs/current/sql-values.html) clause where a target column is a domain over an array or composite type. I'll argue no further with this. David
On 5/8/24 5:44 PM, David Rowley wrote: > On Thu, 9 May 2024 at 04:17, Jonathan S. Katz <jkatz@postgresql.org> wrote: >> * Fix how >> [`INSERT`](https://www.postgresql.org/docs/current/sql-insert.html) >> handles 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. > > Maybe it's only me who thinks the double plural of "VALUES rows" is > hard to parse. If that's the case I'll just drop this as it's not that > important. > > FWIW, I'd probably write: > > * Fix issue with > [`INSERT`](https://www.postgresql.org/docs/current/sql-insert.html) > with a multi-row > [`VALUES`](https://www.postgresql.org/docs/current/sql-values.html) clause > where a target column is a domain over an array or composite type. I like your wording, and went with that. Thanks, Jonathan