aboutsummaryrefslogtreecommitdiff
path: root/contrib/jsonb_plpython/jsonb_plpython2u.control
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2019-01-09 11:35:14 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2019-01-09 11:35:14 -0500
commit59029b6fb71e187c150d12f4c37bb2bf982d3125 (patch)
tree5ef9f96b6ac3219e28e889f30a0171a111a9e078 /contrib/jsonb_plpython/jsonb_plpython2u.control
parenta2b22d8e804511ca7f0f712e8365a6a013b0254e (diff)
downloadpostgresql-59029b6fb71e187c150d12f4c37bb2bf982d3125.tar.gz
postgresql-59029b6fb71e187c150d12f4c37bb2bf982d3125.zip
Update docs & tests to reflect that unassigned OLD/NEW are now NULL.
For a long time, plpgsql has allowed trigger functions to parse references to OLD and NEW even if the current trigger event type didn't assign a value to one or the other variable; but actually executing such a reference would fail. The v11 changes to use "expanded records" for DTYPE_REC variables changed the behavior so that the unassigned variable now reads as a null composite value. While this behavioral change was more or less unintentional, it seems that leaving it like this is better than adding code and complexity to be bug-compatible with the old way. The change doesn't break any code that worked before, and it eliminates a gotcha that often required extra code to work around. Hence, update the docs to say that these variables are "null" not "unassigned" when not relevant to the event type. And add a regression test covering the behavior, so that we'll notice if we ever break it again. Per report from Kristjan Tammekivi. Discussion: https://postgr.es/m/CAABK7uL-uC9ZxKBXzo_68pKt7cECfNRv+c35CXZpjq6jCAzYYA@mail.gmail.com
Diffstat (limited to 'contrib/jsonb_plpython/jsonb_plpython2u.control')
0 files changed, 0 insertions, 0 deletions