<feed xmlns='http://www.w3.org/2005/Atom'>
<title>postgresql.git/src/test/regress/sql, branch master</title>
<subtitle>This is the main PostgreSQL git repository.</subtitle>
<id>http://git.postgresql.org/cgit/postgresql.git/atom?h=master</id>
<link rel='self' href='http://git.postgresql.org/cgit/postgresql.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='http://git.postgresql.org/cgit/postgresql.git/'/>
<updated>2026-09-17T05:24:22Z</updated>
<entry>
<title>Fix assertion after aborting internal subtransaction at transaction end</title>
<updated>2026-09-17T05:24:22Z</updated>
<author>
<name>Fujii Masao</name>
</author>
<published>2026-09-17T05:24:22Z</published>
<link rel='alternate' type='text/html' href='http://git.postgresql.org/cgit/postgresql.git/commit/?id=999ce9bcd80890c3d723e113bb0337c900f9f249'/>
<id>urn:sha1:999ce9bcd80890c3d723e113bb0337c900f9f249</id>
<content type='text'>
Previously, aborting an internal subtransaction during COMMIT or
PREPARE TRANSACTION could cause the following assertion failure.
This could happen, for example, when a deferred constraint trigger fired
at COMMIT and its PL/pgSQL exception block caught an error raised
while executing the trigger function.

    TRAP: failed Assert("s-&gt;blockState == TBLOCK_SUBINPROGRESS || s-&gt;blockState
    == TBLOCK_INPROGRESS || s-&gt;blockState == TBLOCK_IMPLICIT_INPROGRESS ||
    s-&gt;blockState == TBLOCK_PARALLEL_INPROGRESS || s-&gt;blockState ==
    TBLOCK_STARTED"), File: "xact.c", Line: 4851, PID: 73455

An internal subtransaction should be able to be aborted while the parent
transaction is in the COMMIT or PREPARE TRANSACTION phase. However,
RollbackAndReleaseCurrentSubTransaction()'s assertion check previously
did not allow TBLOCK_END and TBLOCK_PREPARE as parent transaction
states, causing the assertion failure.

This commit fixes the assertion check by allowing those two parent
transaction states.

Backpatch to all supported versions.

Reported-by: Fabrízio de Royes Mello &lt;fabrizio@planetscale.com&gt;
Author: Patrick Reynolds &lt;piki@planetscale.com&gt;
Reviewed-by: Fujii Masao &lt;masao.fujii@gmail.com&gt;
Reviewed-by: Chao Li &lt;li.evan.chao@gmail.com&gt;
Reviewed-by: Fabrízio de Royes Mello &lt;fabrizio@planetscale.com&gt;
Discussion: https://postgr.es/m/CABo-N97AeMbWuYTWg-3%3D2DkTR3EkvS%2BFt%3DyEaWB181STsR1mBg%40mail.gmail.com
Backpatch-through: 14
</content>
</entry>
<entry>
<title>Distinguish publication exclusions in object addresses.</title>
<updated>2026-09-17T03:44:21Z</updated>
<author>
<name>Amit Kapila</name>
</author>
<published>2026-09-17T03:44:21Z</published>
<link rel='alternate' type='text/html' href='http://git.postgresql.org/cgit/postgresql.git/commit/?id=94670ba6d560b0738992b9bb7d0313d7d90af1d1'/>
<id>urn:sha1:94670ba6d560b0738992b9bb7d0313d7d90af1d1</id>
<content type='text'>
A pg_publication_rel entry can represent either an explicitly published
relation or a table excluded from a FOR ALL TABLES publication, but the
object address code treated every entry as a published relation without
checking prexcept. EXCEPT entries thus appeared as ordinary
published-table mappings in dependency messages, pg_identify_object(),
and pg_identify_object_as_address().

Report such entries as "publication excluded relation" instead, with
object identities indicating that the table is excluded from the
publication. pg_get_object_address() also accepts this new object type,
so that the output of pg_identify_object_as_address() can still be
passed back to it to look up the same object. "publication relation"
now resolves only non-EXCEPT entries, and "publication excluded
relation" only EXCEPT entries.

Oversight in commit fd366065e06.

Author: Fujii Masao &lt;masao.fujii@gmail.com&gt;
Author: Vignesh C &lt;vignesh21@gmail.com&gt;
Reviewed-by: shveta malik &lt;shveta.malik@gmail.com&gt;
Reviewed-by: Peter Smith &lt;smithpb2250@gmail.com&gt;
Reviewed-by: Zhijie Hou &lt;houzj.fnst@fujitsu.com&gt;
Reviewed-by: Nisha Moond &lt;nisha.moond412@gmail.com&gt;
Reviewed-by: Amit Kapila &lt;amit.kapila16@gmail.com&gt;
Reviewed-by: Chao Li &lt;li.evan.chao@gmail.com&gt;
Reviewed-by: Manuel Reyes Bravo &lt;manuelreyesbravo@gmail.com&gt;
Discussion: https://postgr.es/m/CAHGQGwHfESBexa7fq99EvFCf31av=O9h9udnw22ymxmm6LMZzw@mail.gmail.com
Backpatch-through: 19, where it was introduced
</content>
</entry>
<entry>
<title>Use the join collation when unique-ifying a semijoin's RHS</title>
<updated>2026-09-16T10:09:15Z</updated>
<author>
<name>Alexander Korotkov</name>
</author>
<published>2026-09-16T09:17:53Z</published>
<link rel='alternate' type='text/html' href='http://git.postgresql.org/cgit/postgresql.git/commit/?id=d237a7a83668bc228f7c58f104ffb25cbb607a1a'/>
<id>urn:sha1:d237a7a83668bc228f7c58f104ffb25cbb607a1a</id>
<content type='text'>
A semijoin whose RHS is unique-ified groups the RHS on the expressions in
SpecialJoinInfo.semi_rhs_exprs.  Those were recorded with whatever collation
the RHS expression itself exposes, which need not be the collation the join
compares with.  Neither SortGroupClause nor the pathkey machinery carries a
collation of its own, so both Unique-over-Sort and HashAggregate then grouped
by the wrong equality: values the join considers equal survived, and the
following inner join emitted the outer row once per survivor.

With a non-deterministic collation on one side, "SELECT count(*) FROM t WHERE
c IN (SELECT c0 FROM t2)" therefore counted more rows than the same predicate
reports for the rows of t.

Label each RHS expression with the operator's input collation, the same
treatment process_equivalence() gives to equivalence class members.  Every
consumer of semi_rhs_exprs reads the collation off the expression, so this
fixes the sort-based and hash-based paths together; in the branches where
create_unique_path() also passes these expressions to
relation_has_unique_index_for(), it likewise stops a unique index built with a
different collation from being taken as proof that unique-ification can be
skipped.  The same goes for a subquery's DISTINCT computed under a different
collation, since translate_sub_tlist() punts on the relabeled expressions.

Reported-by: Suyang Zhong &lt;syzhong16@gmail.com&gt;
Author: Andrey Rachitskiy &lt;pl0h0yp1@gmail.com&gt;
Reviewed-by: Tender Wang &lt;tndrwang@gmail.com&gt;
Reviewed-by: Richard Guo &lt;guofenglinux@gmail.com&gt;
Reviewed-by: Alexander Korotkov &lt;aekorotkov@gmail.com&gt;
Discussion: https://postgr.es/m/19633-647cd4c73a84b085%40postgresql.org
Backpatch-through: 14
</content>
</entry>
<entry>
<title>Use hex_decode_safe() to speed up UUID input.</title>
<updated>2026-09-15T22:07:08Z</updated>
<author>
<name>Masahiko Sawada</name>
</author>
<published>2026-09-15T22:07:08Z</published>
<link rel='alternate' type='text/html' href='http://git.postgresql.org/cgit/postgresql.git/commit/?id=72af14bccd2127bf20ddeaf198b78de46e9e892b'/>
<id>urn:sha1:72af14bccd2127bf20ddeaf198b78de46e9e892b</id>
<content type='text'>
Previously, string_to_uuid() decoded one byte at a time, calling
isxdigit() twice and strtoul() once for every pair of hexadecimal
digits. Commit ec8719ccbfcd made hex_decode_safe() decode a run of
hexadecimal digits in bulk, so add a fast path for the two common
shapes: 32 contiguous hexadecimal digits, and the canonical
8x-4x-4x-4x-12x form, each optionally wrapped in braces.

Anything else, and any decoding error, falls back to the
byte-at-a-time parser, so the accepted grammar and the error messages
don't change. hex_decode_safe() also skips whitespace, which the UUID
grammar forbids, so we treat a short decode as an error too. Rejecting
an input that has a fast-path shape therefore costs a second
parse. But this only happens for syntax-error cases, so it's not a
problem in practice.

Reviewed-by: Bharath Rupireddy &lt;bharath.rupireddyforpostgres@gmail.com&gt;
Reviewed-by: Haibo Yan &lt;tristan.yim@gmail.com&gt;
Reviewed-by: Chao Li &lt;li.evan.chao@gmail.com&gt;
Reviewed-by: John Naylor &lt;johncnaylorls@gmail.com&gt;
Discussion: https://postgr.es/m/CAD21AoCqeR4UQU77Q_yOMNNzJ7AVeiO5QZT+4HnzPm4Wm-e02Q@mail.gmail.com
</content>
</entry>
<entry>
<title>Revert UPDATE/DELETE FOR PORTION OF</title>
<updated>2026-09-15T10:12:37Z</updated>
<author>
<name>Peter Eisentraut</name>
</author>
<published>2026-09-15T10:12:37Z</published>
<link rel='alternate' type='text/html' href='http://git.postgresql.org/cgit/postgresql.git/commit/?id=a4b26b8f7cd07a3e7f0cba550c30db142329e065'/>
<id>urn:sha1:a4b26b8f7cd07a3e7f0cba550c30db142329e065</id>
<content type='text'>
List of commits reverted:

  8e72d914c52  Add UPDATE/DELETE FOR PORTION OF
  b6ccd30d8ff  Add isolation tests for UPDATE/DELETE FOR PORTION OF
  33db6c4baf1  Fix DELETE/UPDATE FOR PORTION OF with rules
  7b22f15a015  Add psql tab completion for FOR PORTION OF clause
  7ca8c942967  Fix FOR PORTION OF with non-updatable view columns
  993a7aa0e4a  Fix cross-leftover pollution in FOR PORTION OF insert triggers
  7ac030d5b15  Require UPDATE permission on FOR PORTION OF column
  f0aedc7cb0e  Small terminology fixes in comments
  7d13b03a2e6  Fix FOR PORTION OF for inheritance children
  a272a58b942  Move FOR PORTION OF volatile check into planner
  a40fdf65886  Reject child partition FDWs in FOR PORTION OF
  bc3ae886a75  Forbid FOR PORTION OF with WHERE CURRENT OF
  e994f956e48  Forbid generated columns in FOR PORTION OF
  dfce19c2300  Forbid FOR PORTION OF on views with INSTEAD OF triggers
  20fe90bbb93  Fix RLS checks for FOR PORTION OF leftover rows
  9170c8b7169  Test what BEFORE UPDATE triggers do to FOR PORTION OF
  7090c696cc9  Deparse FOR PORTION OF using the range column's current name.
  62d1a5f8be8  Avoid RETURNING side effects for FOR PORTION OF leftovers.
  9924e2d900b  Enforce WITH CHECK OPTION on DELETE FOR PORTION OF leftovers
  c16a1b4f2ce  Fix error code for null FOR PORTION OF target
  610976420a3  Fix assertion failures in DELETE FOR PORTION OF tuple routing
  438f027238c  Resolve untyped parameters in FOR PORTION OF FROM/TO bounds
  140fdfcdf12  Don't evaluate the FOR PORTION OF target under EXPLAIN

Discussion: https://www.postgresql.org/message-id/62bf70cc-dc33-4188-8070-a8c177bb61de%40eisentraut.org
</content>
</entry>
<entry>
<title>Add battery of tests related TOAST tables with oid8</title>
<updated>2026-09-15T02:30:45Z</updated>
<author>
<name>Michael Paquier</name>
</author>
<published>2026-09-15T02:30:45Z</published>
<link rel='alternate' type='text/html' href='http://git.postgresql.org/cgit/postgresql.git/commit/?id=c68cba09dd7fb2cca1fdddfcf8e0fe206e97a8a4'/>
<id>urn:sha1:c68cba09dd7fb2cca1fdddfcf8e0fe206e97a8a4</id>
<content type='text'>
The tests added by this commit cover a large ground in terms of the
introduction of oid8 in TOAST tables, with the following areas covered,
with all the gaps found during the development of the feature:
- Tables with oid8 TOAST tables in general, under strings.sql.
- ALTER TABLE with attribute manipulations in transactions and different
toast_table_value settings.
- Relation rewrites, not affecting the TOAST relation after initial
creation with VACUUM FULL, CLUSTER, REPACK.
- pg_column_compression().
- test_decoding, for external and extended TOAST data.
- amcheck, external and extended storage with heap checked.
- UPDATE with out-of-line datums that belongs to another TOAST table.
This offers coverage for toast_tuple_init(), where external vartags
could be mixed once multiple on-disk external TOAST pointers can
co-exist.  This pattern can be triggered with asan/ubsan, with an
out-of-bound memcpy when unpatched.

These tests are added before the new vartag_external, mostly as a matter
of avoiding dead code in the tree.

Author: Michael Paquier &lt;michael@paquier.xyz&gt;
Reviewed-by: Greg Burd &lt;greg@burd.me&gt;
Reviewed-by: Bharath Rupireddy &lt;bharath.rupireddyforpostgres@gmail.com&gt;
Reviewed-by: Yugo Nagata &lt;nagata@sraoss.co.jp&gt;
Discussion: https://postgr.es/m/af19kUjwjhaoUTLn@paquier.xy
</content>
</entry>
<entry>
<title>Add support for toast_value_type=oid8</title>
<updated>2026-09-14T23:37:06Z</updated>
<author>
<name>Michael Paquier</name>
</author>
<published>2026-09-14T23:37:06Z</published>
<link rel='alternate' type='text/html' href='http://git.postgresql.org/cgit/postgresql.git/commit/?id=a625fc570c22e199471e1a2656e2c32b8dc0c0fd'/>
<id>urn:sha1:a625fc570c22e199471e1a2656e2c32b8dc0c0fd</id>
<content type='text'>
This commit adds the possibility to define TOAST tables with oid8 as
their chunk_id, based on the reloption toast_value_type.  All the
external TOAST pointers still rely on varatt_external_oid and a single
vartag.  The values inserted in the oid8 TOAST tables are fed from the
OID8 value generator, casted to OID for now, as we do not have a
vartag_external able to store Oid8 values yet.

An upcoming commit will add support for a new vartag_external and its
associated structures, with the code being able to use a different
on-disk external TOAST pointer depending on the attribute type of
chunk_id defined in TOAST relations.

All the changes done here are mechanical, mostly around the TOAST code
that needs to be able to do chunk_id lookups based on the two types now
supported.

Bump catalog version.

Author: Michael Paquier &lt;michael@paquier.xyz&gt;
Reviewed-by: Greg Burd &lt;greg@burd.me&gt;
Reviewed-by: Bharath Rupireddy &lt;bharath.rupireddyforpostgres@gmail.com&gt;
Reviewed-by: Yugo Nagata &lt;nagata@sraoss.co.jp&gt;
Discussion: https://postgr.es/m/af19kUjwjhaoUTLn@paquier.xy
</content>
</entry>
<entry>
<title>Don't let JSON constructor coercions block SQL function inlining</title>
<updated>2026-09-14T08:04:13Z</updated>
<author>
<name>Richard Guo</name>
</author>
<published>2026-09-14T08:04:13Z</published>
<link rel='alternate' type='text/html' href='http://git.postgresql.org/cgit/postgresql.git/commit/?id=9d0adee8768852fc0e5713ec27cf52d46d97279d'/>
<id>urn:sha1:9d0adee8768852fc0e5713ec27cf52d46d97279d</id>
<content type='text'>
contain_context_dependent_node_walker() reports a CaseTestExpr as
context-dependent unless it sits under a simple CaseExpr or the
elemexpr of an ArrayCoerceExpr.  A JsonConstructorExpr whose RETURNING
type requires a coercion also carries a CaseTestExpr placeholder in
that coercion, so any SQL function called with such a constructor as
an argument was refused inlining.

Teach the walker that a CaseTestExpr is expected within the coercion
of a JsonConstructorExpr, the same way it already handles the elemexpr
of an ArrayCoerceExpr.  This is safe now that eval_const_expressions
no longer lets an enclosing simple CASE clobber that placeholder.

Author: Richard Guo &lt;guofenglinux@gmail.com&gt;
Discussion: https://postgr.es/m/CAMbWs48A=VCFbteTkuCoknO1_0-Cu0aMBT0M07dm7vj1QyixDg@mail.gmail.com
Backpatch-through: 19
</content>
</entry>
<entry>
<title>Fix const-folding of JSON constructors inside a simple CASE</title>
<updated>2026-09-14T08:03:41Z</updated>
<author>
<name>Richard Guo</name>
</author>
<published>2026-09-14T08:03:41Z</published>
<link rel='alternate' type='text/html' href='http://git.postgresql.org/cgit/postgresql.git/commit/?id=e17df18a811e082a47d68263c154ae0385cd1494'/>
<id>urn:sha1:e17df18a811e082a47d68263c154ae0385cd1494</id>
<content type='text'>
A JSON constructor with a RETURNING clause uses a CaseTestExpr as the
placeholder for its result in the coercion expression.  When such a
constructor appears in a WHEN clause of a simple CASE whose test
expression is a constant, eval_const_expressions substituted that
constant for the placeholder, so the coercion produced the CASE's test
value instead of the constructor's result.  For instance,

    CASE 'x' WHEN JSON_OBJECT('a': 'b' RETURNING text) THEN 1 ELSE 0 END

evaluated to 1.

To fix, keep case_val out of scope while simplifying the coercion, as
is already done for the elemexpr of an ArrayCoerceExpr.

Back-patch to v16, where the SQL/JSON constructor functions were
introduced.

Author: Richard Guo &lt;guofenglinux@gmail.com&gt;
Discussion: https://postgr.es/m/CAMbWs48A=VCFbteTkuCoknO1_0-Cu0aMBT0M07dm7vj1QyixDg@mail.gmail.com
Backpatch-through: 16
</content>
</entry>
<entry>
<title>Disallow SET UNLOGGED for tables in a publication's EXCEPT clause.</title>
<updated>2026-09-14T04:10:18Z</updated>
<author>
<name>Amit Kapila</name>
</author>
<published>2026-09-14T04:10:18Z</published>
<link rel='alternate' type='text/html' href='http://git.postgresql.org/cgit/postgresql.git/commit/?id=7056ed4663f5ce4214cc1ebce42ec40f4400a7ea'/>
<id>urn:sha1:7056ed4663f5ce4214cc1ebce42ec40f4400a7ea</id>
<content type='text'>
Unlogged tables cannot be replicated, so they can neither be published nor
be named in a publication's EXCEPT clause.  ALTER TABLE ... SET UNLOGGED
checked only whether the table was published, so a table in an EXCEPT
clause could still be made unlogged, leaving a state that CREATE
PUBLICATION would reject and that pg_dump could not restore.

Author: Vignesh C &lt;vignesh21@gmail.com&gt;
Reviewed-by: Amit Kapila &lt;amit.kapila16@gmail.com&gt;
Reviewed-by: Chao Li &lt;li.evan.chao@gmail.com&gt;
Reviewed-by: shveta malik &lt;shveta.malik@gmail.com&gt;
Reviewed-by: Hayato Kuroda &lt;kuroda.hayato@fujitsu.com&gt;
Reviewed-by: Peter Smith &lt;smithpb2250@gmail.com&gt;
Reviewed-by: Zhijie Hou &lt;houzj.fnst@fujitsu.com&gt;
Discussion: https://postgr.es/m/CALDaNm1r2MkGu6h8zgU1Kj1sX-FcMQ7wGTeLSnhx-5joiyXEvg@mail.gmail.com
Backpatch-through: 19, where it was introduced
</content>
</entry>
</feed>
