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
Attachments:
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
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
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
"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]/messages/by-id/18363-e3598a5a572d0699@postgresql.org, 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
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
Attachments:
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]https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=7155cc4a60e7bfc837233b2dea2563a2edc673fd, 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
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
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