Stamp 18.3.
commit : 62d6c7d3df6287f1bd83199c1a746e50d31571a0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 Feb 2026 16:56:43 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 Feb 2026 16:56:43 -0500 M configure
M configure.ac
M meson.build
Translation updates
commit : 1598d06b1490f7ed3a753c688620187403188ed9
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 23 Feb 2026 13:53:35 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 23 Feb 2026 13:53:35 +0100 Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 8edd578f1856e2ac142bb3bb7090ec0a58cd8ac6 M src/backend/po/de.po
M src/backend/po/ja.po
M src/backend/po/ka.po
M src/backend/po/ru.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_combinebackup/po/fr.po
M src/bin/pg_combinebackup/po/ka.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/ja.po
M src/bin/pg_resetwal/po/fr.po
M src/bin/pg_rewind/po/ru.po
M src/bin/psql/po/fr.po
M src/interfaces/libpq/po/fr.po
M src/pl/plpgsql/src/po/ru.po
Release notes for 18.3, 17.9, 16.13, 15.17, 14.22.
commit : 24a590112cfbdac79f98472170c68b944e3a0b07
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 22 Feb 2026 12:22:41 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 22 Feb 2026 12:22:41 -0500 M doc/src/sgml/release-18.sgml
Update .abi-compliance-history for AddRelationNotNullConstraints().
commit : 70eca789eaaaec8346a883a551db371ee5101750
author : Álvaro Herrera <alvherre@kurilemu.de>
date : Sat, 21 Feb 2026 13:08:03 +0100
committer: Álvaro Herrera <alvherre@kurilemu.de>
date : Sat, 21 Feb 2026 13:08:03 +0100 Commit 8d9a97e0bb6d anticipated this change:
1 function with incompatible sub-type changes:
[C] 'function List* AddRelationNotNullConstraints(Relation, List*, List*)' has some sub-type changes:
parameter 4 of type 'List*' was added
Discussion: https://postgr.es/m/19393-6a82427485a744cf@postgresql.org
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2026-02-21%2011%3A27%3A03
Backpatch-through: 18 only M .abi-compliance-history
Avoid name collision with NOT NULL constraints
commit : 8d9a97e0bb6d820dac553848f0d5d8cc3f3e219d
author : Álvaro Herrera <alvherre@kurilemu.de>
date : Sat, 21 Feb 2026 12:22:08 +0100
committer: Álvaro Herrera <alvherre@kurilemu.de>
date : Sat, 21 Feb 2026 12:22:08 +0100 If a CREATE TABLE statement defined a constraint whose name is identical
to the name generated for a NOT NULL constraint, we'd throw an
(unnecessary) unique key violation error on
pg_constraint_conrelid_contypid_conname_index: this can easily be
avoided by choosing a different name for the NOT NULL constraint.
Fix by passing the constraint names already created by
AddRelationNewConstraints() to AddRelationNotNullConstraints(), so that
the latter can avoid name collisions with them.
Bug: #19393
Author: Laurenz Albe <laurenz.albe@cybertec.at>
Reported-by: Hüseyin Demir <huseyin.d3r@gmail.com>
Backpatch-through: 18
Discussion: https://postgr.es/m/19393-6a82427485a744cf@postgresql.org M src/backend/catalog/heap.c
M src/backend/commands/tablecmds.c
M src/include/catalog/heap.h
M src/test/regress/expected/create_table.out
M src/test/regress/sql/create_table.sql
First-draft release notes for 18.3.
commit : c5edc6c8ff4c2d6f116abbc532b1cd130fcfbc17
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Feb 2026 15:31:08 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Feb 2026 15:31:08 -0500 As usual, the release notes for other branches will be made by cutting
these down, but put them up for community review first. M doc/src/sgml/release-18.sgml
Fix expanding 'bounds' in pg_trgm's calc_word_similarity() function
commit : 041e02e6a6110af871b909c55f1a1bd9d5a66cdb
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 20 Feb 2026 11:56:42 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 20 Feb 2026 11:56:42 +0200 If the 'bounds' array needs to be expanded, because the input contains
more trigrams than the initial guess, the code didn't return the
reallocated array correctly to the caller. That could lead to a crash
in the rare case that the input string becomes longer when it's
lower-cased. The only known instance of that is when an ICU locale is
used with certain single-byte encodings. This was an oversight in
commit 00896ddaf41f.
Author: Zsolt Parragi <zsolt.parragi@percona.com>
Backpatch-through: 18 M contrib/pg_trgm/trgm_op.c
Fix computation of varnullingrels when translating appendrel Var
commit : ed57c207c397a6e6a91e0394cacdc63e0f029173
author : Richard Guo <rguo@postgresql.org>
date : Fri, 20 Feb 2026 18:00:02 +0900
committer: Richard Guo <rguo@postgresql.org>
date : Fri, 20 Feb 2026 18:00:02 +0900 When adjust_appendrel_attrs translates a Var referencing a parent
relation into a Var referencing a child relation, it propagates
varnullingrels from the parent Var to the translated Var. Previously,
the code simply overwrote the translated Var's varnullingrels with
those of the parent.
This was incorrect because the translated Var might already possess
nonempty varnullingrels. This happens, for example, when a LATERAL
subquery within a UNION ALL references a Var from the nullable side of
an outer join. In such cases, the translated Var correctly carries
the outer join's relid in its varnullingrels. Overwriting these bits
with the parent Var's set caused the planner to lose track of the fact
that the Var could be nulled by that outer join.
In the reported case, because the underlying column had a NOT NULL
constraint, the planner incorrectly deduced that the Var could never
be NULL and discarded essential IS NOT NULL filters. This led to
incorrect query results where NULL rows were returned instead of being
filtered out.
To fix, use bms_add_members to merge the parent Var's varnullingrels
into the translated Var's existing set, preserving both sources of
nullability.
Back-patch to v16. Although the reported case does not seem to cause
problems in v16, leaving incorrect varnullingrels in the tree seems
like a trap for the unwary.
Bug: #19412
Reported-by: Sergey Shinderuk <s.shinderuk@postgrespro.ru>
Author: Richard Guo <guofenglinux@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/19412-1d0318089b86859e@postgresql.org
Backpatch-through: 16 M src/backend/optimizer/util/appendinfo.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Add translator comment
commit : e3cee403b25831b2e1ddd7786052707ea6b61981
author : Álvaro Herrera <alvherre@kurilemu.de>
date : Thu, 19 Feb 2026 17:11:04 +0100
committer: Álvaro Herrera <alvherre@kurilemu.de>
date : Thu, 19 Feb 2026 17:11:04 +0100 Otherwise the message is not very clear.
Backpatch-through: 18 M src/backend/replication/syncrep.c
Update obsolete comment
commit : 649bd26a4021c2a00999ecea2296c459a21d84dc
author : Álvaro Herrera <alvherre@kurilemu.de>
date : Wed, 18 Feb 2026 18:09:54 +0100
committer: Álvaro Herrera <alvherre@kurilemu.de>
date : Wed, 18 Feb 2026 18:09:54 +0100 table_tuple_update's update_indexes argument hasn't been a boolean since
commit 19d8e2308bc5.
Backpatch-through: 16 M src/include/access/tableam.h
Fix the volatility setting of json{b}_strip_nulls
commit : 2f6ee7b389c2b570ac55eb25273872b729d397c8
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 17 Feb 2026 15:43:32 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 17 Feb 2026 15:43:32 -0500 Commit 4603903d294 unfortunately reset the volatility of these functions
to STABLE whereas they had previously been set to IMMUTABLE. We can't
force a catalog update in the stable release, although a pg_update would
probably do the trick. A simpler fix, though, for affected users is
probably a simple catalog surgery along the lines of:
UPDATE pg_proc SET provolatile = 'i' WHERE oid in (3261,3262);
Applied to 18 only. In master we are planning to get rid of the separate
redeclarations for defaults in system_functions.sql.
Bug: #19409
Reported-By: Lucio Chiessi <lucio.chiessi@trustly.com>
Discussion: https://postgr.es/m/19409-e16cd2605e59a4af@postgresql.org M src/backend/catalog/system_functions.sql
Fix test_valid_server_encoding helper function.
commit : ccc9be800dddf1662aa25aa4ee27aa71965b3fa9
author : Thomas Munro <tmunro@postgresql.org>
date : Tue, 17 Feb 2026 13:53:32 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Tue, 17 Feb 2026 13:53:32 +1300 Commit c67bef3f325 introduced this test helper function for use by
src/test/regress/sql/encoding.sql, but its logic was incorrect. It
confused an encoding ID for a boolean so it gave the wrong results for
some inputs, and also forgot the usual return macro. The mistake didn't
affect values actually used in the test, so there is no change in
behavior.
Also drop it and another missed function at the end of the test, for
consistency.
Backpatch-through: 14
Author: Zsolt Parragi <zsolt.parragi@percona.com> M src/test/regress/expected/encoding.out
M src/test/regress/regress.c
M src/test/regress/sql/encoding.sql
Suppress new "may be used uninitialized" warning.
commit : d04b34d685a2b002d5c1577cbd9f046e827535c7
author : Noah Misch <noah@leadboat.com>
date : Mon, 16 Feb 2026 18:04:58 -0800
committer: Noah Misch <noah@leadboat.com>
date : Mon, 16 Feb 2026 18:04:58 -0800 Various buildfarm members, having compilers like gcc 8.5 and 6.3, fail
to deduce that text_substring() variable "E" is initialized if
slice_size!=-1. This suppression approach quiets gcc 8.5; I did not
reproduce the warning elsewhere. Back-patch to v14, like commit
9f4fd119b2cbb9a41ec0c19a8d6ec9b59b92c125.
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/1157953.1771266105@sss.pgh.pa.us
Backpatch-through: 14 M src/backend/utils/adt/varlena.c
hstore: Fix NULL pointer dereference with receive function
commit : 4a0843c539018a1aad22a3ec8209b0ff1697b65d
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 17 Feb 2026 08:41:30 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 17 Feb 2026 08:41:30 +0900 The receive function of hstore was not able to handle correctly
duplicate key values when a new duplicate links to a NULL value, where a
pfree() could be attempted on a NULL pointer, crashing due to a pointer
dereference.
This problem would happen for a COPY BINARY, when stacking values like
that:
aa => 5
aa => null
The second key/value pair is discarded and pfree() calls are attempted
on its key and its value, leading to a pointer dereference for the value
part as the value is NULL. The first key/value pair takes priority when
a duplicate is found.
Per offline report.
Reported-by: "Anemone" <vergissmeinnichtzh@gmail.com>
Reported-by: "A1ex" <alex000young@gmail.com>
Backpatch-through: 14 M contrib/hstore/hstore_io.c
Don't reset 'latest_page_number' when replaying multixid truncation
commit : 817f74600d0d015309596762c9e4a07e0ac8fdbf
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 16 Feb 2026 17:16:59 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 16 Feb 2026 17:16:59 +0200 'latest_page_number' is set to the correct value, according to
nextOffset, early at system startup. Contrary to the comment, it hence
should be set up correctly by the time we get to WAL replay.
This fixes a failure to replay WAL generated on older minor versions,
before commit 789d65364c (18.2, 17.8, 16.12, 15.16, 14.21). The
failure occurs after a truncation record has been replayed and looks
like this:
FATAL: could not access status of transaction 858112
DETAIL: Could not read from file "pg_multixact/offsets/000D" at offset 24576: read too few bytes.
CONTEXT: WAL redo at 3/2A3AB408 for MultiXact/CREATE_ID: 858111 offset 6695072 nmembers 5: 1048228 (sh) 1048271 (keysh) 1048316 (sh) 1048344 (keysh) 1048370 (sh)
Reported-by: Sebastian Webber <sebastian@swebber.me>
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>
Discussion: https://www.postgresql.org/message-id/20260214090150.GC2297@p46.dedyn.io;lightning.p46.dedyn.io
Backpatch-through: 14-18 M src/backend/access/transam/multixact.c
M src/include/access/slru.h
pgcrypto: Tweak error message for incorrect session key length
commit : 770d13dd063cb5fb89953a0ffb68b70be716ffa6
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 16 Feb 2026 12:18:28 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 16 Feb 2026 12:18:28 +0900 The error message added in 379695d3cc70 referred to the public key being
too long. This is confusing as it is in fact the session key included
in a PGP message which is too long. This is harmless, but let's be
precise about what is wrong.
Per offline report.
Reported-by: Zsolt Parragi <zsolt.parragi@percona.com>
Backpatch-through: 14 M contrib/pgcrypto/expected/pgp-pubkey-session.out
M contrib/pgcrypto/px.c
Fix SUBSTRING() for toasted multibyte characters.
commit : 6e045e1a6e3f1a55d3d246f8258f3316410b26f6
author : Noah Misch <noah@leadboat.com>
date : Sat, 14 Feb 2026 12:16:16 -0800
committer: Noah Misch <noah@leadboat.com>
date : Sat, 14 Feb 2026 12:16:16 -0800 Commit 1e7fe06c10c0a8da9dd6261a6be8d405dc17c728 changed
pg_mbstrlen_with_len() to ereport(ERROR) if the input ends in an
incomplete character. Most callers want that. text_substring() does
not. It detoasts the most bytes it could possibly need to get the
requested number of characters. For example, to extract up to 2 chars
from UTF8, it needs to detoast 8 bytes. In a string of 3-byte UTF8
chars, 8 bytes spans 2 complete chars and 1 partial char.
Fix this by replacing this pg_mbstrlen_with_len() call with a string
traversal that differs by stopping upon finding as many chars as the
substring could need. This also makes SUBSTRING() stop raising an
encoding error if the incomplete char is past the end of the substring.
This is consistent with the general philosophy of the above commit,
which was to raise errors on a just-in-time basis. Before the above
commit, SUBSTRING() never raised an encoding error.
SUBSTRING() has long been detoasting enough for one more char than
needed, because it did not distinguish exclusive and inclusive end
position. For avoidance of doubt, stop detoasting extra.
Back-patch to v14, like the above commit. For applications using
SUBSTRING() on non-ASCII column values, consider applying this to your
copy of any of the February 12, 2026 releases.
Reported-by: SATŌ Kentarō <ranvis@gmail.com>
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>
Bug: #19406
Discussion: https://postgr.es/m/19406-9867fddddd724fca@postgresql.org
Backpatch-through: 14 M src/backend/utils/adt/varlena.c
M src/test/regress/expected/encoding.out
M src/test/regress/sql/encoding.sql
pg_mblen_range, pg_mblen_with_len: Valgrind after encoding ereport.
commit : 4174e41b9e9ee552fff3501e73a1897c9f1eecaa
author : Noah Misch <noah@leadboat.com>
date : Sat, 14 Feb 2026 12:16:16 -0800
committer: Noah Misch <noah@leadboat.com>
date : Sat, 14 Feb 2026 12:16:16 -0800 The prior order caused spurious Valgrind errors. They're spurious
because the ereport(ERROR) non-local exit discards the pointer in
question. pg_mblen_cstr() ordered the checks correctly, but these other
two did not. Back-patch to v14, like commit
1e7fe06c10c0a8da9dd6261a6be8d405dc17c728.
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>
Discussion: https://postgr.es/m/20260214053821.fa.noahmisch@microsoft.com
Backpatch-through: 14 M src/backend/utils/mb/mbutils.c
Improve error message for checksum failures in pgstat_database.c
commit : 5b0e0c3d03ebbc09ad2534cfb26aa440b21c7ba0
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 13 Feb 2026 12:17:12 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 13 Feb 2026 12:17:12 +0900 This log message was referring to conflicts, but it is about checksum
failures. The log message improved in this commit should never show up,
due to the fact that pgstat_prepare_report_checksum_failure() should
always be called before pgstat_report_checksum_failures_in_db(), with a
stats entry already created in the pgstats shared hash table. The three
code paths able to report database-level checksum failures follow
already this requirement.
Oversight in b96d3c389755.
Author: Wang Peng <215722532@qq.com>
Discussion: https://postgr.es/m/tencent_9B6CD6D9D34AE28CDEADEC6188DB3BA1FE07@qq.com
Backpatch-through: 18 M src/backend/utils/activity/pgstat_database.c
Make pg_numa_query_pages() work in frontend programs
commit : b08033944e7932265c4cb37cd19ceda2147e6cd7
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 12 Feb 2026 19:41:06 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 12 Feb 2026 19:41:06 +0200 It's currently only used in the server, but it was placed in src/port
with the idea that it might be useful in client programs too. However,
it will currently fail to link if used in a client program, because
CHECK_FOR_INTERRUPTS() is not usable in client programs. Fix that by
wrapping it in "#ifndef FRONTEND".
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>
Discussion: https://www.postgresql.org/message-id/21cc7a48-99d9-4f69-9a3f-2c2de61ac8e5%40iki.fi
Backpatch-through: 18 M src/port/pg_numa.c
Fix plpgsql's handling of "return simple_record_variable".
commit : ce4b7e3a1058eb3edd7511f2770379d7f78bd3a0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 11 Feb 2026 16:53:14 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 11 Feb 2026 16:53:14 -0500 If the variable's value is null, exec_stmt_return() missed filling
in estate->rettype. This is a pretty old bug, but we'd managed not
to notice because that value isn't consulted for a null result ...
unless we have to cast it to a domain. That case led to a failure
with "cache lookup failed for type 0".
The correct way to assign the data type is known by exec_eval_datum.
While we could copy-and-paste that logic, it seems like a better
idea to just invoke exec_eval_datum, as the ROW case already does.
Reported-by: Pavel Stehule <pavel.stehule@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CAFj8pRBT_ahexDf-zT-cyH8bMR_qcySKM8D5nv5MvTWPiatYGA@mail.gmail.com
Backpatch-through: 14 M src/pl/plpgsql/src/expected/plpgsql_domain.out
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/sql/plpgsql_domain.sql
Fix pg_stat_get_backend_wait_event() for aux processes
commit : 53463b4b2484c9523a248de90c097b1394501d86
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 11 Feb 2026 18:50:57 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 11 Feb 2026 18:50:57 +0200 The pg_stat_activity view shows information for aux processes, but the
pg_stat_get_backend_wait_event() and
pg_stat_get_backend_wait_event_type() functions did not. To fix, call
AuxiliaryPidGetProc(pid) if BackendPidGetProc(pid) returns NULL, like
we do in pg_stat_get_activity().
In version 17 and above, it's a little silly to use those functions
when we already have the ProcNumber at hand, but it was necessary
before v17 because the backend ID was different from ProcNumber. I
have other plans for wait_event_info on master, so it doesn't seem
worth applying a different fix on different versions now.
Reviewed-by: Sami Imseih <samimseih@gmail.com>
Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/c0320e04-6e85-4c49-80c5-27cfb3a58108@iki.fi
Backpatch-through: 14 M src/backend/utils/adt/pgstatfuncs.c
Further stabilize a postgres_fdw test case.
commit : 946b653b7ab9f5c41f153cac7f05fe94772d8319
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 11 Feb 2026 11:03:01 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 11 Feb 2026 11:03:01 -0500 The buildfarm occasionally shows a variant row order in the output
of this UPDATE ... RETURNING, implying that the preceding INSERT
dropped one of the rows into some free space within the table rather
than appending them all at the end. It's not entirely clear why that
happens some times and not other times, but we have established that
it's affected by concurrent activity in other databases of the
cluster. In any case, the behavior is not wrong; the test is at fault
for presuming that a seqscan will give deterministic row ordering.
Add an ORDER BY atop the update to stop the buildfarm noise.
The buildfarm seems to have shown this only in v18 and master
branches, but just in case the cause is older, back-patch to
all supported branches.
Discussion: https://postgr.es/m/3866274.1770743162@sss.pgh.pa.us
Backpatch-through: 14 M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
doc: Mention all SELECT privileges required by INSERT ... ON CONFLICT.
commit : 7233e70537da6a9e6f1f383c3a2bed73fc121b62
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 11 Feb 2026 10:52:59 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 11 Feb 2026 10:52:59 +0000 On the INSERT page, mention that SELECT privileges are also required
for any columns mentioned in the arbiter clause, including those
referred to by the constraint, and clarify that this applies to all
forms of ON CONFLICT, not just ON CONFLICT DO UPDATE.
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Reviewed-by: Viktor Holmberg <v@viktorh.net>
Discussion: https://postgr.es/m/CAEZATCXGwMQ+x00YY9XYG46T0kCajH=21QaYL9Xatz0dLKii+g@mail.gmail.com
Backpatch-through: 14 M doc/src/sgml/ref/insert.sgml
doc: Clarify RLS policies applied for ON CONFLICT DO NOTHING.
commit : dfc15bd3286dc7828c7666bfca06c76252305517
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 11 Feb 2026 10:25:06 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 11 Feb 2026 10:25:06 +0000 On the CREATE POLICY page, the description of per-command policies
stated that SELECT policies are applied when an INSERT has an ON
CONFLICT DO NOTHING clause. However, that is only the case if it
includes an arbiter clause, so clarify that.
While at it, also clarify the comment in the regression tests that
cover this.
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Reviewed-by: Viktor Holmberg <v@viktorh.net>
Discussion: https://postgr.es/m/CAEZATCXGwMQ+x00YY9XYG46T0kCajH=21QaYL9Xatz0dLKii+g@mail.gmail.com
Backpatch-through: 14 M doc/src/sgml/ref/create_policy.sgml