public inbox for [email protected]  
help / color / mirror / Atom feed
From: Bruce Momjian <[email protected]>
To: jian he <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: First draft of PG 17 release notes
Date: Thu, 9 May 2024 11:08:34 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CACJufxG_1=aRBHEvfGUjgjs_KVmc6bBQdmSns8u0wEta-idy2Q@mail.gmail.com>
References: <[email protected]>
	<CACJufxG_1=aRBHEvfGUjgjs_KVmc6bBQdmSns8u0wEta-idy2Q@mail.gmail.com>

On Thu, May  9, 2024 at 06:53:30PM +0800, jian he wrote:
> On Thu, May 9, 2024 at 12:04 PM Bruce Momjian <[email protected]> wrote:
> > I have committed the first draft of the PG 17 release notes;  you can
> > see the results here:
> >
> >         https://momjian.us/pgsql_docs/release-17.html
> >
> 
> * Add function pg_buffercache_evict() to allow shared buffer eviction
> (Palak Chaturvedi, Thomas Munro)
> * This is useful for testing.
> 
> this should put it on the section
> < E.1.3.11. Additional Modules
> ?

Oh, it is in the pg_buffercache module --- I should have realized that
from the name, fixed.

> Then I found out official release notes don't have <section> attributes,
> so it doesn't matter?

Uh, what are sections?  Did previous release notes have it?

> I think this commit title "Add hash support functions and hash opclass
> for contrib/ltree."
>  from [1] is more descriptive.

Uh, I don't think people know what hash support functions are, but they
know what hash indexes are, and maybe hash joins and hash aggregates. 
Why do you consider the commit text better?

> i am not 100% sure of the meaning of "This is useful for extensions."

The commit says:

	commit 2b5154beab7
	Author: Tom Lane <[email protected]>
	Date:   Fri Oct 20 12:28:38 2023 -0400
	
	    Extend ALTER OPERATOR to allow setting more optimization attributes.
	
	    Allow the COMMUTATOR, NEGATOR, MERGES, and HASHES attributes to be set
	    by ALTER OPERATOR.  However, we don't allow COMMUTATOR/NEGATOR to be
	    changed once set, nor allow the MERGES/HASHES flags to be unset once
	    set.  Changes like that might invalidate plans already made, and
	    dealing with the consequences seems like more trouble than it's worth.
-->	    The main use-case we foresee for this is to allow addition of missed
-->	    properties in extension update scripts, such as extending an existing
-->	    operator to support hashing.  So only transitions from not-set to set
	    states seem very useful.

-- 
  Bruce Momjian  <[email protected]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.






view thread (146+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: First draft of PG 17 release notes
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox