CI tests run on a branch where a commit is pushed or a pull-request is
created, with the corresponding PostgreSQL version.  Also, there is a
scheduled test on every Sunday.

This is required as of the creation of the new branch PG17, as it is the
new branch created for compatibility of pg_hint_plan with PostgreSQL 17.

Thinko in 9087784.

Backpatch-through: 17

Running installcheck on a cluster with compute_query_id disabled would
cause the tests to fail because it is not possible to retrieve the query
ID on the first call of get_query_id().  compute_query_id is forcibly
set when enabling the hint table, which is something this test relies
on, so let's just set pg_hint_plan.enable_hint_table in this case.

Per offline report from the author.

Author: Yogesh Sharma
Backpatch-through: 17

This test expects query IDs to be computed without the hint table,
checking that compute_query_id is either "on" or "auto" when running the
tests.  The test would fail should compute_query_id be set to off on a
cluster where the regression tests are run.

There are no reasons why the test should not just use compute_query_id =
on now that we don't depend on pg_stat_statements anymore since
8e296b6 for the regression tests of pg_hint_plan.  So let's just
force it, improving the portability of the tests.

Backpatch-through: 17

pg_hint_plan has depended for a long time on a set of non-portable shell
scripts to filter the output of the plans of any unstable output, like
costs or widths.  This had the disadvantage to be usable only on Linux,
while depending on \o and temporary output files.

This is replaced in this commit by a solution closer to PostgreSQL
upstream, where we use a PL/pgSQL function to process the EXPLAIN
queries whose output need to be stabilized.  The style used in this
commit may arguably be improved more in the future, but the changes done
here make the diffs more pallatable than anything I have considered,
with all the plans generated remaining the same.

Some queries that included quotes in ut-R required a couple more quotes
to work in the filtering function.  Some extra CONTEXT messages coming
from the filtering function are generated, as well as some extra LOG
messages for cases related unused indexes, but let's live with that for
now.

Author: Yogesh Sharma, Michael Paquier
Backpatch-through: 17

Per pull request #198 and issue #181.

Since 8e296b6, the tests can run without pg_stat_statements, so
let's make things lighter as well in the CI.  While on it, remove the
dependency to file_fdw in shared_preload_libraries: this is not required
as the library does not need to be loaded for the sake of the regression
tests.

As a result of the discussion with Sami Imseih, this commit adds tests
showing that for empty tables, only parallel index scans can be enforced
and not sequential scans.  This is an old, historical, rather weird
behavior, that may not be worth changing in the long run as empry tables
are not something users rely a lot when using pg_hint_plan, but let's
add a test tracking if any future change impacts the plans generated.

Author: Sami Imseih
Backpatch-through: 17

Per discussion on issue #164.

session_preload_libraries was not really required with its set of ALTER
DATABASE SET commands to updates some GUCs.  There were equivalent LOAD
and SET commands used in the tests where session_preload_libraries was
defined, and the same GUCs were set twice.

This simplifies the tests, while shaving some cycles to run the tests.

Backpatch-through: 17

Upstream never had support for library unloading, and it has been
officially simplified in ab02d702ef08.  Let's do the same for
pg_hint_plan, to shave some code.

Backpatch-through: 17

This is required for the next release, to be in sync with the planner
code pg_hint_plan depends on.

Backpatch-through: 17

As coded, the logic in charge of computing parallel_workers based on the
lookup of the paths would assign AppendPath before making sure that it
is a node of the expected type.  The code was not wrong, but that would
encourage incorrect logic, like looking at the values inside the
AppendPath before checking that it is of the correct type.

Backpatch-through: 17

An environment enabling pg_hint_plan.enable_hint_table while
pg_hint_plan has not been created as an extension would fail all its
queries as the table created by the extension does not exist.

This commit adds a check at the top of get_hints_from_table() to check
if the extension is installed before attempting to use the hint table,
generating a WARNING.  We have discussed about a few options, but a
WARNING is more consistent with how duplicated hints or compute_query_id
disabled are handled.

This does not completely close the failure hole, though, as it is still
possible to see the table lookup failure for the CREATE EXTENSION
command enabling pg_hint_plan as an extension if enable_hint_table is
enabled.  In terms of code simplicity, I am not really convinced that
we need to do more just for that.

This commit relies on 490f869d92e5 that has introduced syscache entries
for pg_extension.  On stable branches, we will need a different logic
with a check on the table itself with its namespace.

Idea based on some feedback from Julien Rouhaud.  The tests are from me.

Author: Sami Imseih, Michael Paquier

Backpatch-through: 12

Per issue #191.

Some tests have been generating diffs when linking pg_hint_plan to LLVM,
and generated extra information in the plans without changing their
stability.  Let's disable JIT in the tests where this happened, for now,
improving the stability of the tests.

Per issue #199.

Reported-by: Shinya Kato
Backpatch-through: 17

Bumps [jinja2](https://github.com/pallets/jinja) from 3.1.4 to 3.1.6.
- [Release notes](https://github.com/pallets/jinja/releases)
- [Changelog](https://github.com/pallets/jinja/blob/main/CHANGES.rst)
- [Commits](pallets/jinja@3.1.4...3.1.6)

---
updated-dependencies:
- dependency-name: jinja2
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <[email protected]>