Re: PG 16 draft release notes ready

Jonathan S. Katz <jkatz@postgresql.org>

From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-05-23T22:38:37Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Revert MAINTAIN privilege and pg_maintain predefined role.

  2. doc: PG 16 relnotes, remove "Have initdb use ICU by default"

  3. initdb: change default --locale-provider back to libc.

  4. doc: PG 16 relnotes, add author

  5. doc: PG 16 relnotes, move memory item and reword OUTER item

  6. doc: PG 16 relnotes, add memory overhead reduction item

  7. doc: PG 16 relnotes, adjust subscription origin mention

  8. doc: PG 16 relnotes, adjust auto_explain logging item

  9. doc: PG 16 relnotes: adjust outer/full hash join parallelization

  10. doc: PG 16 relnotes, fix duplicate author and commit

  11. doc: PG 16 relnotes, fix "locale" typo and windows locale text

  12. doc: PG 16 relnotes, add author from previous merge

  13. doc: PG 16 relnotes, wording adjustments

  14. doc: PG 16 relnotes, merge and move vector items

  15. doc: PG 16 relnotes, update xid/subxid searches item

  16. doc: PG 16 relnotes, SIMD improvements

  17. doc: PG 16 relnotes, add major features list

  18. doc: PG 16 relnotes, misc merged items and bootstrap detail

  19. doc: PG 16 relnotes, misc. updates

  20. doc: PG 16 relnotes, add commits

  21. Allow logical decoding on standbys

  22. Fix ts_headline() edge cases for empty query and empty search text.

  23. Add a hook for modifying the ldapbind password

  24. Rework design of functions in pg_walinspect

  25. initdb: derive encoding from locale for ICU; similar to libc.

  26. Doc: add XML ID attributes to <sectN> and <varlistentry> tags.

  27. Simplify the implementations of the to_reg* functions.

  28. Rename pg_dissect_walfile_name() to pg_split_walfile_name()

  29. Make materialized views participate in predicate locking

  30. Improve performance of and reduce overheads of memory management

  31. Allow grant-level control of role inheritance behavior.

On 5/22/23 4:18 PM, Robert Haas wrote:
> On Sun, May 21, 2023 at 3:05 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>> * Support for regular expressions for matching usernames and databases
>> names in `pg_hba.conf`, and user names in `pg_ident.conf`
> 
> I suggest that this is not a major feature.
> 
> Perhaps the work that I did to improve CREATEROLE could be considered
> for inclusion in the major features list. In previous releases,
> someone with CREATEROLE can hack the PG OS account. Now they can't. In
> previous releases, someone with CREATEROLE can manage all
> non-superuser roles, but now they can manage the roles they create (or
> ones they are given explicit authority to manage). You can even
> control whether or not such users automatically inherit the privileges
> of roles they create, as superusers inherit all privileges. There is
> certainly some argument that this is not a sufficiently significant
> set of changes to justify a major feature mention, and even if it is,
> it's not clear to me exactly how it would be best worded. And yet I
> feel like it's very likely that if we look back on this release in 3
> years, those changes will have had a significant impact on many
> PostgreSQL deployments, above all in the cloud, whereas I think it
> likely that the ability to have regular expressions in pg_hba.conf and
> pg_ident.conf will have had very little effect by comparison.
> 
> Of course, there is always a possibility that I'm over-estimating the
> impact of my own work.

In general, I'm completely fine with people advocating for their own 
features during this process, in case there's something that I missed.

For this case, while I think this work is very impactful, but I don't 
know if I'd call it a major feature vs. modifying an unintended 
behavior. Additionally, folks have likely put mitigations in place for 
this through the years. I'm happy to be convinced otherwise.

The regular expressions in the files adds an ability that both we didn't 
have before, and has been a request I've heard from users with very 
large deployments. For them, it'll help simplify a lot of their 
configurations/automations for setting this up en masse. Again, I'm 
happy to be convinced otherwise.

I wanted to use the beta release to allow for us to see 1/ how people 
ultimately test these things and 2/ help better sift out what will be 
called a major feature. We could end up shuffling items in the list or 
completely rewriting it, so it's not set in stone.

Thanks,

Jonathan