On Fri, Jul 29, 2022 at 10:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wrote: > I think the parser should've prevented this. It's in charge of > rejecting overlength SELECT lists, for example. Also, the limit > probably needs to be just MaxTupleAttributeNumber.
Concretely, about as attached.
In the existing code, if you just supply 10000 or so columns you reach this error in heaptuple.c:
if (numberOfAttributes > MaxTupleAttributeNumber) ereport(ERROR, (errcode(ERRCODE_TOO_MANY_COLUMNS), errmsg("number of columns (%d) exceeds limit (%d)", numberOfAttributes, MaxTupleAttributeNumber)));
I borrowed the errcode from that, but the wording from parse_node.c:
if (pstate->p_next_resno - 1 > MaxTupleAttributeNumber) ereport(ERROR, (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED), errmsg("target lists can have at most %d entries", MaxTupleAttributeNumber)));
I'm a bit inclined to adjust parse_node.c to also use TOO_MANY_COLUMNS (54011) instead of the generic PROGRAM_LIMIT_EXCEEDED (54000).
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.
