pá 4. 1. 2019 v 17:44 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Kristjan Tammekivi <kristjantammekivi@gmail.com> writes: > I've noticed a change in the behaviour in triggers / hstores in Postgres > 11.1 when compared to Postgres 10.5. > [ reference to OLD in an insert trigger doesn't throw error anymore ]
Hmm. This seems to be a side effect of the changes we (I) made in v11 to rationalize the handling of NULL vs ROW(NULL,NULL,...) composite values in plpgsql. The "unassigned" trigger row variables are now acting as though they are plain NULL values. I'm not sure now whether I realized that this would happen --- it looks like there are not and were not any regression test cases that would throw an error for the disallowed-reference case, so it's quite possible that it just escaped notice.
The old behavior was pretty darn squirrely; in particular it would let you parse but not execute a reference to "OLD.column", a behavior that could not occur for any other composite variable. Now that'll just return NULL. In a green field I don't think there'd be complaints about this behavior --- I know lots of people have spent considerable effort programming around the other behavior.
While I haven't looked closely, I think duplicating the old behavior would require adding a special-purpose flag to plpgsql DTYPE_REC variables, which'd cost a little performance (extra error checks in very hot code paths) and possibly break compatibility with pldebugger, if there's been a v11 release of that.
So I'm a bit inclined to accept this behavior change and adjust the documentation to say that OLD/NEW are "null" rather than "unassigned" when not relevant.
It is maybe unwanted effect, but it is not bad from my view. new behave is consistent - a initial value of variables is just NULL
