]> granicus.if.org Git - postgresql/commit
Mark read/write expanded values as read-only in ValuesNext(), too.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 3 Jun 2016 22:07:14 +0000 (18:07 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 3 Jun 2016 22:07:14 +0000 (18:07 -0400)
commit8355897ff296a3634f6b9c3da444622a02adda9c
treeb07cf5bbe57ec17b9834f4b000c627d9fc71a759
parenta102f98e26bc7d21eb5246fd345f8e3ab31be109
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.
src/backend/executor/nodeValuesscan.c
src/test/regress/expected/plpgsql.out
src/test/regress/sql/plpgsql.sql