pá 4. 1. 2019 v 17:44 odesílatel Tom Lane <t...@sss.pgh.pa.us> napsal:
> Kristjan Tammekivi <kristjantammek...@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 +1 Pavel > Thoughts? > > regards, tom lane > >
