Hi, On 2023-01-15 15:53:09 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > For the purpose here a limit of MaxTupleAttributeNumber or such instead of > > FUNC_MAX_ARGS would do the trick, I think? > > As long as we have to change the code, we might as well remove the > arbitrary restriction.
WFM, just wanted to be sure we thought about the errors it could cause. I'm not sure we've exercised cases of tuples being too wide due to variable-width plain storage types exhaustively. There's only a small number of these types: int2vector, oidvector, gtsvector, tsquery What's behind using plain for these types? Is it just because we want to use it in tables that don't have a toast table (namely pg_index)? Obviously we can't change the storage in existing releases... > > Should this be repalloc0? I don't know if the palloc0 above was just used > > with > > the goal of initializing the "header" fields, or also to avoid trailing > > uninitialized bytes? > > I think probably the palloc0 was mostly about belt-and-suspenders > programming. But yeah, its only real value is to ensure that all > the header fields are zero, so I don't think we need repalloc0 > when enlarging. After we set the array size at the end of the > loop, it'd be a programming bug to touch any bytes beyond that. Agreed. Greetings, Andres Freund