Re: BUG #19627: 32,768 trigger arguments wrap `tgnargs` and are silently lost at runtime - Mailing list pgsql-bugs

From Kyotaro Horiguchi
Subject Re: BUG #19627: 32,768 trigger arguments wrap `tgnargs` and are silently lost at runtime
Date
Msg-id 20260819.115636.1952223713943679969.horikyota.ntt@gmail.com
Whole thread
Responses Re: psql variable substitution in plpgsql loop
List pgsql-bugs
At Tue, 18 Aug 2026 09:33:12 +0000, PG Bug reporting form <noreply@postgresql.org> wrote in 
> `CREATE TRIGGER` accepts 32,768 arguments, builds and stores the complete
> `tgargs` payload, but narrows the list length from `int` to `int16` without
> a
> limit check. The catalog stores `tgnargs = -32768`.
...
> ## Affected version
> 
> Reproduced twice on PostgreSQL 18.4 Debug and twice on optimized Release.
> The
> checked current source still assigns `list_length(stmt->args)` directly to
> an
> `int16`.

I think that's correct.  Since list_length() returns an int here, I
think it is sufficient to simply make nargs an int so that we can
check the upper limit.  It would also be possible to increase the
limit, but this patch simply enforces the current internal limit.  The
error message follows the one used in AggregateCreate().

The same code goes back at least to PostgreSQL 14, and the attached
patch can be applied as-is to all versions since then.

Regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment

pgsql-bugs by date:

Previous
From: Andrey Rachitskiy
Date:
Subject: Re: BUG #19621: Unexpected results of JSON_VALUE with DEFAULT ON EMPTY
Next
From: Zsolt Parragi
Date:
Subject: Re: Possible G2-item at SERIALIZABLE