Hi,
On 2023-01-15 15:53:09 -0500, Tom Lane wrote:
> Andres Freund <andres@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