aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2022-08-01 12:22:35 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2022-08-01 12:22:35 -0400
commit5d280bc89336694875444d5d99c1fa0dff232816 (patch)
treede599b305e46c5692e13c56f1a95219a1eed34c7 /src/backend/executor/nodeModifyTable.c
parent24872bbf9288d8949b3f2ed60c0f3ef12015016f (diff)
downloadpostgresql-5d280bc89336694875444d5d99c1fa0dff232816.tar.gz
postgresql-5d280bc89336694875444d5d99c1fa0dff232816.zip
Check maximum number of columns in function RTEs, too.
I thought commit fd96d14d9 had plugged all the holes of this sort, but no, function RTEs could produce oversize tuples too, either via long coldeflists or just from multiple functions in one RTE. (I'm pretty sure the other variants of base RTEs aren't a problem, because they ultimately refer to either a table or a sub-SELECT, whose widths are enforced elsewhere. But we explicitly allow join RTEs to be overwidth, as long as you don't try to form their tuple result.) Per further discussion of bug #17561. As before, patch all branches. Discussion: https://postgr.es/m/17561-80350151b9ad2ad4@postgresql.org
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions