On 31.08.25 16:34, Tom Lane wrote:
> I think our past practice has been to list any one item either in
> Migration or the following sections, not in both places. This item
> seems to adhere to that too: I don't see that commit hash anywhere
> else. So I'm not clear why you're finding this duplicative?
I don't have the complete picture of how the release notes are composed.
I just wanted to add some helpful advice relevant to the migration to
PG18, and the Migration section seemed the right place for it.
Looking at it closer, I think this practice you are describing is
inferior. For one thing, it makes the "Changes" section incomplete: It
should be labeled, "Changes except the ones already listed above". More
importantly, it constrains how the advice in the Migration section can
be structured. It has to be a change description tied to specific
commits and credit, whereas as someone doing the migration, I'm looking
for differently-structured advice.
For example, looking at the item in the Migration section
* Remove column pg_backend_memory_contexts.parent (Melih Mutlu) §
This is no longer needed since pg_backend_memory_contexts.path was
added.
This might be ok as a summary of a description of a code change. But as
someone doing a migration, I don't know what to do with that. If I'm
using PG17 and I'm using the old column, now what?
As another example, the advice on how to handle the change to checksum
enable by default in pg_upgrade is very terse and barely useful.
The Migration section should be written like "If you are using ... then
you should be doing ... {before|after} upgrading."
This can be inferred from many of the items, but several of them not.
