Alexander Lakhin <exclusion@gmail.com> writes:
> So maybe the fix for the bug can be seen as a supplement for 18c0b4ecc.
Yeah, I agree. Given that precedent, there's little excuse for
ExecEvalArrayExpr not to use palloc0; the fact that it doesn't
already was just an oversight in 18c0b4ecc.
I realized that there's a completely separate way in which
ExecEvalArrayExpr is a few bricks shy of a load: it fails to check
for overflow of the output array size.
Pushed the discussed changes along with a fix for that.
regards, tom lane