aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2016-06-03 18:07:14 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2016-06-03 18:07:14 -0400
commit9eaf5be5067571febf323337fc58bcac97b9f5d5 (patch)
treef6b711ad2eda22b26fb2c64cddc4bc3eb512b329 /src/backend/executor/nodeModifyTable.c
parent69f526aa4947135f2570c4ec545f6387d4b14585 (diff)
downloadpostgresql-9eaf5be5067571febf323337fc58bcac97b9f5d5.tar.gz
postgresql-9eaf5be5067571febf323337fc58bcac97b9f5d5.zip
Mark read/write expanded values as read-only in ValuesNext(), too.
Further thought about bug #14174 motivated me to try the case of a R/W datum being returned from a VALUES list, and sure enough it was broken. Fix that. Also add a regression test case exercising the same scenario for FunctionScan. That's not broken right now, because the function's result will get shoved into a tuplestore between generation and use; but it could easily become broken whenever we get around to optimizing FunctionScan better. There don't seem to be any other places where we put the result of expression evaluation into a virtual tuple slot that could then be the source for Vars of further expression evaluation, so I think this is the end of this bug.
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions