Re: BUG #17561: Server crashes on executing row() with very long argument list - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17561: Server crashes on executing row() with very long argument list
Date
Msg-id 3822706.1659113869@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17561: Server crashes on executing row() with very long argument list  (Richard Guo <guofenglinux@gmail.com>)
Responses Re[2]: BUG #17561: Server crashes on executing row() with very long argument list
List pgsql-bugs
Richard Guo <guofenglinux@gmail.com> writes:
> The patch looks good to me. Just wondering if there are any other types
> of expressions that need to check for MaxTupleAttributeNumber in
> parse_expr.c.

As far as I can think, sub-SELECTs and ROW constructs are the only
SQL that can produce composites of non-pre-determined types.
For constructs producing named composite types, the limit on the
number of columns in a table should take care of it.

What I'm more troubled by is whether there are any ways to produce
a wide tuple that don't come through either the parser or a table
definition.  Not sure what that could look like, other than C code
randomly constructing a RowExpr or some such.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Richard Guo
Date:
Subject: Re: BUG #17561: Server crashes on executing row() with very long argument list
Next
From: Jacob Champion
Date:
Subject: Re: RFC 9266: Channel Bindings for TLS 1.3 support