Re: BUG #19627: 32,768 trigger arguments wrap `tgnargs` and are silently lost at runtime

On Wed, Aug 19, 2026 at 11:56:36AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 18 Aug 2026 09:33:12 +0000, PG Bug reporting form <noreply(at)postgresql(dot)org> wrote in
>> 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`.

Fun find.

> 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().

- int16 nargs = list_length(stmt->args);
+ int nargs = list_length(stmt->args);
int len = 0;

+ Assert(nargs >= 0);
+ if (nargs > INT16_MAX)
+ ereport(ERROR,
+ errcode(ERRCODE_TOO_MANY_ARGUMENTS),
+ errmsg("triggers cannot have more than %d arguments",
+ INT16_MAX));

Yeah, that sounds like a solution find enough in practice.

As a side exercise, I have been looking at other catalogs with
smallints like this one. There are quite a few (proc, index,
partition keys, but triggers look like the only hole of this kind we
had.

Will fix that. Thanks for the report and the patch.
--
Michael