Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. First-draft release notes for 16.3.

  1. 2024-05-09 release announcement draft

    Jonathan S. Katz <jkatz@postgresql.org> — 2024-05-06T17:44:05Z

    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

  2. Re: 2024-05-09 release announcement draft

    Erik Rijkers <er@xs4all.nl> — 2024-05-06T20:59:51Z

    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'

  3. Re: 2024-05-09 release announcement draft

    David Rowley <dgrowleyml@gmail.com> — 2024-05-06T21:08:57Z

    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

  4. Re: 2024-05-09 release announcement draft,2024-05-09 release announcement draft

    Sutou Kouhei <kou@clear-code.com> — 2024-05-06T21:36:17Z

    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

  5. Re: 2024-05-09 release announcement draft

    Jonathan S. Katz <jkatz@postgresql.org> — 2024-05-07T02:58:49Z

    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

  6. Re: 2024-05-09 release announcement draft,2024-05-09 release announcement draft

    Jonathan S. Katz <jkatz@postgresql.org> — 2024-05-07T03:02:27Z

    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

  7. Re: 2024-05-09 release announcement draft

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-05-07T03:04:46Z

    "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

  8. Re: 2024-05-09 release announcement draft

    David Rowley <dgrowleyml@gmail.com> — 2024-05-07T03:05:18Z

    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

  9. Re: 2024-05-09 release announcement draft

    Jonathan S. Katz <jkatz@postgresql.org> — 2024-05-07T03:09:24Z

    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

  10. Re: 2024-05-09 release announcement draft

    David Rowley <dgrowleyml@gmail.com> — 2024-05-07T03:27:49Z

    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

  11. Re: 2024-05-09 release announcement draft

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-05-07T03:48:52Z

    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

  12. Re: 2024-05-09 release announcement draft

    David Rowley <dgrowleyml@gmail.com> — 2024-05-07T04:02:37Z

    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

  13. Re: 2024-05-09 release announcement draft

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-05-07T04:16:56Z

    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

  14. Re: 2024-05-09 release announcement draft

    Noah Misch <noah@leadboat.com> — 2024-05-07T18:14:24Z

    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.

  15. Re: 2024-05-09 release announcement draft

    Jonathan S. Katz <jkatz@postgresql.org> — 2024-05-08T16:17:13Z

    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

  16. Re: 2024-05-09 release announcement draft

    David Rowley <dgrowleyml@gmail.com> — 2024-05-08T21:44:02Z

    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

  17. Re: 2024-05-09 release announcement draft

    Jonathan S. Katz <jkatz@postgresql.org> — 2024-05-08T22:04:15Z

    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