| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, kyzevan23(at)mail(dot)ru, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #17561: Server crashes on executing row() with very long argument list |
| Date: | 2022-07-29 16:57:49 |
| Message-ID: | 3822706.1659113869@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Richard Guo <guofenglinux(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jacob Champion | 2022-07-29 17:28:19 | Re: RFC 9266: Channel Bindings for TLS 1.3 support |
| Previous Message | Richard Guo | 2022-07-29 16:24:06 | Re: BUG #17561: Server crashes on executing row() with very long argument list |