From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: First draft of the PG 15 release notes |
Date: | 2022-05-11 15:26:58 |
Message-ID: | YnvVwv1SmGocrl+y@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 11, 2022 at 04:12:23PM +0200, Álvaro Herrera wrote:
> I think this item is pointless:
>
> Remove unused function parameter in get_qual_from_partbound() (Hou Zhijie)
>
> it's just a C-level code, and we don't document such API changes. If we
> were to document them all, it'd be a very very long document.
Okay, removed. I had added it because of this commit text:
This is an external function that extensions could use, so this is
potentially a breaking change. No external callers are known, however,
and this will make it simpler to write such callers in the future.
> Here:
> Improve the algorithm used to compute random() (Fabien Coelho)
>
> This will cause setseed() followed by random() to return a different
> value than on older servers.
> Maybe it's clearer as "This will cause random() sequences to differ from
> what was emitted by prior versions for the same seed values." If I
> don't know anything about the random() API, I understand this as saying
> that setseed() returns a value, and we only changed that value when
> random() is called afterwards.
Yes, better, thanks.
> Here:
> Fix ALTER TRIGGER RENAME on partitioned tables to rename partitions
> (Arne Roland, Álvaro Herrera)
>
> Also prohibit cloned triggers from being renamed.
>
> "... to rename the corresponding triggers on partitions.
>
> Also prohibit such triggers on partitions from being renamed."
> (It's not the *partitions* that are renamed but the triggers,
> obviously.)
Okay, new text:
Fix ALTER TRIGGER RENAME on partitioned tables to properly rename
triggers an all partitions (Arne Roland, Álvaro Herrera)
> Here:
> Add server variable recursive_worktable_factor to allow the user to
> specify the expected recursive query worktable size (Simon Riggs)
>
> WHAT IS A WORKTABLE? NOT DEFINED.
> Do we need to explain in the relnotes that this is relevant to planning
> of WITH RECURSIVE queries?
You mean the syntax? I figured "recursive query" was enough, but the
item clearly needs help.
> Generate periodic log message during slow server starts (Nitin Jadhav,
> Robert Haas, Álvaro Herrera)
> Please credit only Nitin and Robert, not me. I only edited the docs.
Okay, done.
> Allow members of the pg_checkpointer predefined role to run the
> CHECKPOINT command (Jeff Davis)
>
> The 11-era entry said that we *added* new roles for the tasks, and I
> think we should do likewise here:
> Add predefined role pg_checkpointer that enables to run CHECKPOINT
> Otherwise it sounds like pg_checkpointer already existed and we gave it
> this new responsibility.
Agreed, much better. New text:
Add predefined role pg_checkpointer that allows members to run
CHECKPOINT (Jeff Davis)
> Here:
> Create unlogged sequences and allow them to be skipped in logical
> replication (Peter Eisentraut)
> This is not specific to logical replication, actually; it's a generic
> new feature of sequences. So I don't think it belongs in the logical
> replication section. But it's not clear to me where to put it.
Oh, yeah, I had it there because that was its value, but now that we
don't replication sequences, it needs to moved. I put it in the "Data
Types" section.
> Here:
> Add SQL MERGE command to adjust one table to match another (Pavan
> Deolasee, Álvaro Herrera, Amit Langote, Simon Riggs)
> I'm not sure this accurately describes the purpose of the command.
> Maybe "Add SQL MERGE command that allows to run INSERT, UPDATE, DELETE
> subcommands based on another table or the output of a query."
Uh, that sounds odd to me, though I realize it is accurate.
> Also, it doesn't belong in the Utilities section. Maybe it should be in
> the SELECT,INSERT section, and rename the section to something like
> "SQL Queries", and put the whole JSON subsection inside that section
Uh, SQL queries seems very vague --- isn't SELECT the only actual query,
and if not, aren't all commands queries.
> (rather than inside the Functions section).
> I think Simon should appear as first author here.
Done.
> Add new protocol message TARGET to specify a new COPY method to be for
> base backups (Robert Haas)
> I think this one should be in some other section, maybe "Streaming
> Replication and Recovery".
I didn't think anyone cared about the protocol so I put it in Source
Code.
>
> Add server variable archive_library to specify the library to be called
> for archiving (Nathan Bossart)
> Maybe "Allow site-specific WAL archiving, which may no longer use shell
> commands." or something to that effect? The reference to a library is
> a bit obscure.
I added this sentence below it:
Previously only shell commands could be called to perform archiving.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2022-05-11 15:57:19 | Re: Estimating HugePages Requirements? |
Previous Message | Alvaro Herrera | 2022-05-11 15:23:27 | Re: Should use MERGE use BulkInsertState ? |