Re: First draft of PG 19 release notes - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: First draft of PG 19 release notes
Date
Msg-id alwfUMjJ8NADFEF9@momjian.us
Whole thread
In response to Re: First draft of PG 19 release notes  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers
On Sat, Jul 18, 2026 at 06:03:09AM +0800, Chao Li wrote:
> Hi Bruce,
> 
> This feature has been reverted by 372b8d1adb76740123791e9ded4f665b175f5bf5, so you need to delete the item from the
v19release note. 
 
> 
> <!--
> Author: Tom Lane <tgl@sss.pgh.pa.us>
> 2025-09-29 [ef38a4d97] Add GROUP BY ALL.
> -->

I have updated the release notes to match current git;  updated output
is at:

    https://momjian.us/pgsql_docs/

Patch attached.  I added the psql \crosstabview item as an
incompatibility.  I didn't add this commit:

    commit 0c15b715c65
    Author: Tom Lane <tgl@sss.pgh.pa.us>
    Date:   Tue Jun 30 17:21:23 2026 -0400
    
        Disallow set-returning functions within window OVER clauses.
    
        We previously allowed this, but it leads to odd behaviors, basically
        because putting a SRF there is inconsistent with the principle that a
        window function doesn't change the number of rows in the query result.
        There doesn't seem to be a strong reason to try to make such cases
        behave consistently.  Users should put their SRFs in lateral FROM
        clauses instead.
    
        This issue has been sitting on the back burner for multiple years
        now, partially because it didn't seem wise to back-patch such a
        change.  Let's squeeze it into v19 before it's too late.

because I assumed its use was rare enough and the error message clear
enough.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Attachment

pgsql-hackers by date:

Previous
From: 신성준
Date:
Subject: Re: Row pattern recognition
Next
From: Amit Kapila
Date:
Subject: Re: REASSIGN OWNED vs. relisshared dep on !relisshared