PG17 added foreach_ptr, foreach_int and foreach_oid macros
Relevant PG commit
14dd0f27d7cd56ffae9ecdbe324965073d01a9ff
postgres/postgres@14dd0f2

We already have these macros, but they are different with the
PG17 ones because our macros take a DECLARED variable, whereas
the PG16 macros declare a locally-scoped loop variable themselves.

Hence I am renaming our macros to foreach_declared_

Relevant PG commit
d060e921ea5aa47b6265174c32e1128cebdbc3df
postgres/postgres@d060e92

Relevant PG commit
041b96802efa33d2bc9456f2ad946976b92b5ae1
postgres/postgres@041b968

Relevant PG commit:
89e5ef7e21812916c9cf9fcf56e45f0f74034656
postgres/postgres@89e5ef7

Relevant PG commit:
08e6344fd6423210b339e92c069bb979ba4e7cd6
postgres/postgres@08e6344

Relevant PG commit:
f696c0cd5f299f1b51e214efc55a22a782cc175d
postgres/postgres@f696c0c

Relevant PG commit:
de3600452b61d1bc3967e9e37e86db8956c8f577
postgres/postgres@de36004

Relevant PG commit:
ecb0fd33720fab91df1207e85704f382f55e1eb7
postgres/postgres@ecb0fd3

Relevant PG commit:
4f622503d6de975ac87448aea5cea7de4bc140d5
postgres/postgres@4f62250

Relevant PG commit:
012460ee93c304fbc7220e5b55d9d0577fc766ab
postgres/postgres@012460e

Relevant PG commit:
50c67c2019ab9ade8aa8768bfe604cd802fe8591
postgres/postgres@50c67c2

Relevant PG commit:
509199587df73f06eda898ae13284292f4ae573a
postgres/postgres@5091995

Relevant PG commit:
75680c3d805e2323cd437ac567f0677fdfc7b680
postgres/postgres@75680c3

Relevant PG commit:
0294df2f1f842dfb0eed79007b21016f486a3c6c
postgres/postgres@0294df2

Relevant PG commit:
5de890e3610d5a12cdaea36413d967cf5c544e20
postgres/postgres@5de890e

…ON_COUNT

Relevant PG commit:
a6be0600ac3b71dda8277ab0fcbe59ee101ac1ce
postgres/postgres@a6be060

Relevant PG commit:
9e9931d2bf40e2fea447d779c2e133c2c1256ef3
postgres/postgres@9e9931d

Relevant PG commits:
28f3915b73f75bd1b50ba070f56b34241fe53fd1
postgres/postgres@28f3915

ab355e3a88de745607f6dd4c21f0119b5c68f2ad
postgres/postgres@ab355e3

024c521117579a6d356050ad3d78fdc95e44eefa
postgres/postgres@024c521

Relevant PG commit:
03734a7fed7d924679770adb78a7db8a37d14188
postgres/postgres@03734a7

…CORD Vars.

Relevant PG commit:
e0e492e5a928e9c9eda01eeebadcfc36f9f8e7b7
postgres/postgres@e0e492e

Relevant PG commit:
2075ba9dc9af8833b1147996c15246e44a1e4fab
postgres/postgres@2075ba9

Relevant PG commit:
97957fdbaa429c7c582d4753b108cb1e23e1b28a
postgres/postgres@97957fd

Relevant PG commit:
29275b1d177096597675b5c6e7e7c9db2df8f4df
postgres/postgres@29275b1

Relevant PG commit:
dbbca2cf299b81299112ca6ada671a36235ec008
postgres/postgres@dbbca2c

Relevant PG commit:
33e729c5148c3a697abc552621b34bdc5fd497ed
postgres/postgres@33e729c

Relevant PG commit:
c649fa24a42ba89bf5460c7110e4fc8eeca65959
postgres/postgres@c649fa2

…rameters.

Relevant PG commit:
fd0398fcb099980fbedbb7750356ef234408c1c9
postgres/postgres@fd0398f

Relevant PG commit:
6185c9737cf48c9540782d88f12bd2912d6ca1cc
postgres/postgres@6185c97

Relevant PG commit:
0294df2f1f842dfb0eed79007b21016f486a3c6c
postgres/postgres@0294df2

Relevant PG commit:
de3600452b61d1bc3967e9e37e86db8956c8f577
postgres/postgres@de36004

Relevant PG commit:
87c21bb9412c8ba2727dec5ebcd74d44c2232d11
postgres/postgres@87c21bb

Relevant PG commit:
f6a2529920cff76cb6e37ea840122574404dde8b
postgres/postgres@f6a2529

Relevant PG commit:
bb766cde63b4f624d029b34c9cdd3d0a94fd5b46
postgres/postgres@bb766cd

Relevant PG commit:
8461424fd717877ead0706984ef9b6440b2a97ad
postgres/postgres@8461424

Relevant PG commit:
a42fc1c903b54ba94374e5e0c08905b9a1479f19
postgres/postgres@a42fc1c

…ING.

Relevant PG commit:
5c5bccef211cfc98e0d6c4bc1af40a33c8ac2488
postgres/postgres@5c5bcce

In PG17, the outer loop in acquire_sample_rows() changed
from
while (BlockSampler_HasMore(&bs))
to
while (table_scan_analyze_next_block(scan, stream))

Relevant PG commit:
041b96802efa33d2bc9456f2ad946976b92b5ae1
postgres/postgres@041b968

It is expected that the scan_analyze_next_block function will
check if there are any blocks left. So we add that check in
columnar_scan_analyze_next_block

PG 17 added support for DEFAULT in ALTER TABLE .. SET ACCESS METHOD

Relevant PG commit:
d61a6cad6418f643a5773352038d0dfe5d3535b8
postgres/postgres@d61a6ca

In that case, name in AlterTableCmd would be null.
Add a null check here to avoid crash.

…tests

Fix pg15 pg16 multi_mx_create_table multi_schema_support

Relevant PG commit:
postgres/postgres@f696c0c
f696c0cd5f299f1b51e214efc55a22a782cc175d

This commit also has to do with renaming of
daticulocale to datlocale

Relevant PG commit:
f696c0cd5f299f1b51e214efc55a22a782cc175d
postgres/postgres@f696c0c

Keeping this commit separate from the previous one because
these changes will be different once we drop PG15 support.

For now I renamed pg_ge_15_options to pg_ge_15_17_options
and together with it I changed the meaning of the variable.

However when we drop PG14 support, we will use pg_ge_17_options
and delete pg_ge_15_options altogether

Relevant PG commit:
f69319f2f1fb16eda4b535bcccec90dff3a6795e
postgres/postgres@f69319f

This PR addresses a regression test failure in the multi-mx feature of
Citus with the new PostgreSQL 17 version. The regression was identified
during the execution of multi-node tests, specifically targeting
compatibility issues introduced with PostgreSQL 17.

---------

Co-authored-by: Mehmet YILMAZ <[email protected]>