fix some line break logic

Remove pgpa_fix_scan_or_clump_member.

address XXX by addingg comments

remove obsolete XXX

Append nodes bearing non-relation RTIs are ordinary

this isn't really a correct fix

rework for scans

This seems to actually kind of work, but there are definitely some things
that are broken.

In particular, PARTITIONWISE() advice is being emitted for plans where
Append nodes are induced by setops rather than by table inheritance;
and what looks like extra PARTITIONWISE() advice is also being emitted
for non-obvious reasons in some table inheritance cases.

Also, INDEX_SCAN(), INDEX_ONLY_SCAN(), and BITMAP_HEAP_SCAN() output
needs revising, and ORDINARY_SCAN() output needs suppressing.

reindent

renaming, phase 2

renaming, phase 1

reclassify clumped joins as scans

upgrades

context->walker

PGPAQF_SEMIJOIN_(NON_)UNIQUE

add query features earlier before considering elided nodes

Remove pgpa_gathered_join -- query features make it is obsolete.

First stab at SJ_UNIQUE.

add query_feature thing -- this implies removing gathered_join, not done

stuff

add "clear" functions

remove old file

trim shared advice

EXPLAIN (PLAN_ADVICE)

add missing dsa_pin call

pgindent

pg_get_collected_shared_advice

add ability to store in the shared collector

pgindent

comments, skip storage of empty advice

somewhat-working local collection

start some advice storage ideas in motion

add stuff

More work on output stuff.

There is doubtless a lot of stuff still wrong here, but it's way
closer to what I actually want.

fix duplicate clumped-join creation

output restructuring and miscellaneous cleanup

debug_out -> output

add constants for enum length

Move wrap_column into pgpa_output_context

pgindent

Introduce output context object.

add some line wrapping logic

move more code to pgpa_output.c

move debug output routines to a new file

filter join RTIs out of clumped joins to avoid failures

reintroduce range table identifiers

breaks the regression tests in a few places, because join RTIs leak
into clumped joins

more comments

more comments

pgindent

Refactoring.

remove more code not required by the regression tests

remove apparently-unnecessary Result node traversal

add some comments

use pgpa_descend_node more

cleanup, incidental bug fix

fix various things so regression tests pass

fix subplan walking because i never get this right

Couple of bug fixes and tweaks.

I suspect there are residual problems with decomposing joins, but
this is better.

temporary debugging hack

update makefile

remove XXX

output something for GATHER and GATHER_MERGE

tidy up some cosmetics

Look through Gather and Gather Merge nodes.

Insist that a purported scan node must have an RTI.

attempt to fix handling of multiple elided nodes

also add a bunch of comments to pgpa_plan_walker

first elided node -> last elided node

add a comment

hackity hack elided nodes

hackity, hack

hackity hack

fix a few bugs

debugging code that shows it doesn't work

this prints out unrolled joins in a fairly raw format, and the result
is we can see we're not unrolling anything

Remove unused field.

pgpa_join_strategy renaming

fix some stuff

Start trying to get a proper treewalk oraganized.

See various XXX things in this commit. There's a bunch of stuff that
isn't right here. But I think it's closer to being right than the old
thing, since I believe we need several coordinated pgpa subsystems to
concurrently walk the tree.

remove junk

pgpa_join.c

pgpa_join.h

This is wrong insofar as the thinking about the ElidedNode case is
not in the comments, and maybe we should actually store the ElidedNode
in the arrays.

Port pg_plan_advice over from the subplanname branch.

Re-add build system integration.

thing

more

Store information about elided nodes in the final plan.

When setrefs.c removes a SubqueryScan, single-child Append, or
single-child MergeAppend from the final Plan tree, the RTI which
would have been scanned by the removed node no longer appears in
the final plan (the actual range table entry is still present,
but it's no longer referenced).

That's fine for the executor, but it can create difficulties for
code that wants to deduce from the final plan what choices were
made during the planing process. For example, a traversal of a
join tree in the final plan might never encounter the RTI of one
of the relationss in the join problem, and might instead encounter
a scan of a child RTI or even one from a different subquery level.

This patch adjusts things so that each time we elide a node during
setrefs processing, we record the plan_node_id of its single surviving
child, the type of the removed node, and the RTIs that the removed
node would have scanned. This information is recorded in a separate
list that can be ignored by the executor and examined only by code
that cares about these details.

This commit also updates pg_overexplain to display these details.

Store information about range-table flattening in the final plan.

During planning, there is one range table per subquery; at the end if
planning, those separate range tables are flattened into a single
range table. Prior to this change, it was impractical for code
examining the final plan to understand which parts of the flattened
range table came from which subquery's range table.

If the only consumer of the final plan is the executor, that is
completely fine. However, if some code wants to examine the final
plan, or what happens when we execute it, and extract information from
it that be used in future planning cycles, it's inconvenient.  So,
this commit remembers in the final plan which part of the final range
table came from which subquery's range table.

Additionally, this commit teaches pg_overexplain'e RANGE_TABLE option
to display the subquery name for each range table entry.

Give subplans names that are known while planning that subplan.

Previously, subplans were shown in EXPLAIN output identified by
a number, like "InitPlan 1", and some were identified by a name,
like "CTE foo". Now, each subplan gets a name, which for InitPlans
and SubPlans is based on the type of sublink e.g. expr_1 or any_1,
and these names are guaranteed to be unique across the whole plan.

The numerical portion of the name may be different than it was
previously, because InitPlan 1 meant the first subplan that we
finished planning (which happened to be an InitPlan). This number
couldn't be known at the time we began planning that subplan,
because the query planner might recurse into other subplans which
would then be fully planned before finishing the plan at the outer
level. These new subplan names are assigned when we *start* planning
a subplan, which allows extensions that affect planning to know the
name that will ultimately be assigned while planning is still in
progress.

Some subplans aren't shown as subplans in EXPLAIN output. This
happens when the subquery is a FROM-cluse item or a branch of a
set operation, rather than, for example, an expression that will
be transformed into something render as an InitPlan or SubPlan.
These subplans also get unique names, although those names are not
currently shown in the EXPLAIN output. This means that it's now
possible to use unique, human-readable names to refer to any
subplan within a query; only the topmost query level is nameless.

Assert that RTIs of joined rels are discoverable from join plans.

Every RTI that appears in the joinrel's relid set should be findable
via the outer or inner plan, except for join RTIs which aren't
necessarily preserved in the final plan. This is a requirement if
we want to be able to reliably determine the chosen join order from
the final plan, although it's not sufficient for that goal of itself,
due to further problems created by setrefs-time processing.

Note that this depends on the earlier commit to add a relids field to
Result nodes; without that change, a join tree involving two or more
Result nodes would be fundamentally ambiguous (and even a join tree
involving one could only be interpreted by guessing at its origin).

Consider a Result node's relids in ExplainPreScanNode.

Now that a Result node has a relids set, add the relids that it
carries the set accumulated by ExplainPreScanNode so that we
generate unique relation aliases for all of the referenced relations
when it calls select_rtable_names_for_explain. The effect of this
changes is that a few things get schema-qualified in the regression
test outputs that previously were not. In similar cases not involving
a Result node, we were already schema-qualifying, so this appears to
be an improvement.

XXX. I have broken this out as a separate commit for now; however,
it could be merged with the commit to add 'relids' to 'Result'; or
the patch series could even be rejiggered to present this as the
primary benefit of that change, leaving the EXPLAIN changes as a
secondary benefit, instead of the current organization, which does
the reverse.

Keep track of what RTIs a Result node is scanning.

Result nodes now include an RTI set, which is only non-NULL when they
have no subplan, and is taken from the relid set of the RelOptInfo
that the Result is generating.

Using that information, EXPLAIN now emits, where relevant, a "Replaces" line
that says whether it replaced a scan, a join, or an aggregate; and in the
former two cases, which relations were involved.

Likewise, pg_overexplain's EXPLAIN (RANGE_TABLE) now displays the RTIs
stored in a Result node just as it already does for other RTI-bearing
node types.

Don't retreat slot's confirmed_flush LSN.

Prevent moving the confirmed_flush backwards, as this could lead to data
duplication issues caused by replicating already replicated changes.

This can happen when a client acknowledges an LSN it doesn't have to do
anything for, and thus didn't store persistently. After a restart, the
client can send the prior LSN that it stored persistently as an
acknowledgement, but we need to ignore such an LSN to avoid retreating
confirm_flush LSN.

Diagnosed-by: Zhijie Hou <houzj.fnst@fujitsu.com>
Author: shveta malik <shveta.malik@gmail.com>
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>
Tested-by: Nisha Moond <nisha.moond412@gmail.com>
Backpatch-through: 13
Discussion: https://postgr.es/m/CAJpy0uDZ29P=BYB1JDWMCh-6wXaNqMwG1u1mB4=10Ly0x7HhwQ@mail.gmail.com
Discussion: https://postgr.es/m/OS0PR01MB57164AB5716AF2E477D53F6F9489A@OS0PR01MB5716.jpnprd01.prod.outlook.com

Doc: add pre-branch task to run src/tools/copyright.pl.

It's common for some files with last year's copyright date
to sneak into the tree between early January (when we normally run
copyright.pl) and feature freeze.  Immediately before branching
the new release is an ideal time to fix the stragglers, so add a
note about it to the RELEASE_CHANGES checklist.

Discussion: https://postgr.es/m/CALa6HA4_Wu7-2PV0xv-Q84cT8eG7rTx6bdjUV0Pc=McAwkNMfQ@mail.gmail.com

Fix incorrect year in some copyright notices

A couple of new files have been added in the tree with a copyright year
of 2024 while we were already in 2025.  These should be marked with
2025, so let's fix them.

Reported-by: Shaik Mohammad Mujeeb <mujeeb.sk.dev@gmail.com>
Discussion: https://postgr.es/m/CALa6HA4_Wu7-2PV0xv-Q84cT8eG7rTx6bdjUV0Pc=McAwkNMfQ@mail.gmail.com

ecpg: Add missing newline in meson.build

Noticed while performing a routine sanity check of the files in the
tree.  Issue introduced by 28f04984f0c2.

Discussion: https://postgr.es/m/CALa6HA4_Wu7-2PV0xv-Q84cT8eG7rTx6bdjUV0Pc=McAwkNMfQ@mail.gmail.com

Fix tuple_fraction calculation in generate_orderedappend_paths()

6b94e7a6da adjusted generate_orderedappend_paths() to consider fractional
paths.  However, it didn't manage to interpret the tuple_fraction value
correctly.  According to the header comment of grouping_planner(), the
tuple_fraction >= 1 specifies the absolute number of expected tuples.  That
number must be divided by the expected total number of tuples to get the
actual fraction.

Even though this is a bug fix, we don't backpatch it.  The risks of the side
effects of plan changes on stable branches are too high.

Reported-by: Andrei Lepikhov <lepihov@gmail.com>
Discussion: https://postgr.es/m/3ca271fa-ca5c-458c-8934-eb148622b270%40gmail.com
Author: Andrei Lepikhov <lepihov@gmail.com>
Reviewed-by: Junwang Zhao <zhjwpku@gmail.com>
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>

Make our usage of memset_s() conform strictly to the C11 standard.

Per the letter of the C11 standard, one must #define
__STDC_WANT_LIB_EXT1__ as 1 before including <string.h> in order to
have access to memset_s().  It appears that many platforms are lenient
about this, because we weren't doing it and yet the code appeared to
work anyway.  But we now find that with -std=c11, macOS is strict and
doesn't declare memset_s, leading to compile failures since we try to
use it anyway.  (Given the lack of prior reports, perhaps this is new
behavior in the latest SDK?  No matter, we're clearly in the wrong.)

In addition to the immediate problem, which could be fixed merely by
adding the needed #define to explicit_bzero.c, it seems possible that
our configure-time probe for memset_s() could fail in case a platform
implements the function in some odd way due to this spec requirement.
This concern can be fixed in largely the same way that we dealt with
strchrnul() in 6da2ba1d8: switch to using a declaration-based
configure probe instead of a does-it-link probe.

Back-patch to v13 where we started using memset_s().

Reported-by: Lakshmi Narayana Velayudam <dev.narayana.v@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CAA4pTnLcKGG78xeOjiBr5yS7ZeE-Rh=FaFQQGOO=nPzA1L8yEA@mail.gmail.com
Backpatch-through: 13

Fix function name reference in comment

Ensure that we refer to the function being used, rather than the
name of the resulting function in question.

Author: Paul A Jungwirth <pj@illuminatedcomputing.com>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/CA+renyVZNiHEv5ceKDjA4j5xC6NT6mRuW33BDERBQMi_90_t6A@mail.gmail.com

Align organization wording in copyright statement

This aligns the copyright and legal notice wordig with commit
a233a603bab8 and pgweb commit 2d764dbc083ab8.  Backpatch down
to all supported versions.

Author: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Dave Page <dpage@pgadmin.org>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/744E414E-3F52-404C-97FB-ED9B3AA37DC8@yesql.se
Backpatch-through: 13

Fix Assert failure in XMLTABLE parser

In an XMLTABLE expression, columns can be marked NOT NULL, and the
parser internally fabricates an option named "is_not_null" to
represent this.  However, the parser also allows users to specify
arbitrary option names.  This creates a conflict: a user can
explicitly use "is_not_null" as an option name and assign it a
non-Boolean value, which violates internal assumptions and triggers an
assertion failure.

To fix, this patch checks whether a user-supplied name collides with
the internally reserved option name and raises an error if so.
Additionally, the internal name is renamed to "__pg__is_not_null" to
further reduce the risk of collision with user-defined names.

Reported-by: Евгений Горбанев <gorbanyoves@basealt.ru>
Author: Richard Guo <guofenglinux@gmail.com>
Reviewed-by: Alvaro Herrera <alvherre@kurilemu.de>
Discussion: https://postgr.es/m/6bac9886-65bf-4cec-96bd-e304159f28db@basealt.ru
Backpatch-through: 15

Add explicit initialization for all PlannerGlobal fields

When creating a new PlannerGlobal node in standard_planner(), most
fields are explicitly initialized, but a few are not.  This doesn't
cause any functional issues, as makeNode() zeroes all fields by
default.  However, the inconsistency is undesirable from a clarity and
maintenance perspective.

This patch explicitly initializes the remaining fields to improve
consistency and readability.

Author: Richard Guo <guofenglinux@gmail.com>
Reviewed-by: David Rowley <dgrowleyml@gmail.com>
Discussion: https://postgr.es/m/CAMbWs4-TgQHNOiouqGcuHoBqbJjWyx4UxGKxUY3FrF4trGbcPA@mail.gmail.com

Fix order of parameters in POD documentation

The documentation for log_check() had the parameters in the wrong
order.  Also while there, rename %parameters to %params to better
documentation for similar functions which use %params.  Backpatch
down to v14 where this was introduced.

Author: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/9F503B5-32F2-45D7-A0AE-952879AD65F1@yesql.se
Backpatch-through: 14

Fix the race condition in the test added by 7c99dc587.

After executing ALTER SUBSCRIPTION tap_sub SET PUBLICATION, we did not
wait for the new walsender process to restart. As a result, an INSERT
executed immediately after the ALTER could be decoded and skipped,
considering it is not part of any subscribed publication. And, the old
apply worker could also confirm the LSN of such an INSERT. This could
cause the replication to resume from a point after the INSERT. In such
cases, we miss the expected warning about the missing publication.

To fix this, ensure the walsender has restarted before continuing after
ALTER SUBSCRIPTION.

Reported-by: Tom Lane as per CI
Author: vignesh C <vignesh21@gmail.com>
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Discussion: https://postgr.es/m/1230066.1745992333@sss.pgh.pa.us

Add tab-complete for ALTER DOMAIN ADD  [CONSTRAINT]

We can add tab-completion with "CHECK (" and "NOT NULL" after ALTER
DOMAIN ADD [CONSTRAINT].

ALTER DOMAIN dom ADD -> CHECK (
ALTER DOMAIN dom ADD -> NOT NULL
ALTER DOMAIN dom ADD -> CONSTRAINT
ALTER DOMAIN dom ADD CONSTRAINT nm -> CHECK (
ALTER DOMAIN dom ADD CONSTRAINT nm -> NOT NULL

Author: jian he <jian.universality@gmail.com>
Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://postgr.es/m/CACJufxG_f6LzAT_McC-kKmQWpuWnOYKyNBw8Kv3xzTjPqmeHcA@mail.gmail.com

Fix comment of tsquerysend()

The comment describes the order in which fields are sent, and it had one
of the fields in the wrong place.

This has been wrong since e6dbcb72fafa (2008), so backpatch all the way
back.

Author: Emre Hasegeli <emre@hasegeli.com>
Discussion: https://postgr.es/m/CAE2gYzzf38bR_R=izhpMxAmqHXKeM5ajkmukh4mNs_oXfxcMCA@mail.gmail.com

relcache: Avoid memory leak on tables with no CHECK constraints

As complained about by Valgrind, in commit a379061a22a8 I failed to
realize that I was causing rd_att->constr->check to become allocated
when no CHECK constraints exist; previously it'd remain NULL.  (This was
my bug, not the mentioned commit author's).  Fix by making the
allocation conditional, and set ->check to NULL if unallocated.

Reported-by: Yasir <yasir.hussain.shah@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/202505082025.57ijx3qrbx7u@alvherre.pgsql

Sort includes in alphabetical order

Added by commit 042a66291b04, no backpatch needed.