po 27. 4. 2020 v 16:26 odesÃlatel Greg Stark <st...@mit.edu> napsal:
> On Fri, 24 Apr 2020 at 10:08, Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > I'm skeptical. If we'd marked them that way from day one, it would have > > been fine, but to change it now is a whole different discussion. I think > > the odds that anybody will thank us are much smaller than the odds that > > there will be complaints. In particular, I'd be just about certain that > > there are people out there who are changing FOUND and loop control > > variables manually, and they will not appreciate us breaking their code. > > I kind of doubt it would break anybody's code. But I also doubt it's > actually going to help anybody. It's not exactly an easy bug to write, > so meh, I can't really get worked up either way about this. > > > As for the trigger variables specifically, what is the rationale > > for marking TG_OP read-only but not OLD and NEW? But it is dead > > certain that we won't get away with making the latter two read-only. > > But, uh, this actually seems like it might help people. Obviously we > can't make NEW constant for BEFORE triggers, but for AFTER triggers it > would actually be catching quite an easy-to-write bug. I bet plenty of > people accidentally define triggers as AFTER triggers which are > intending to modify the columns being stored and then don't understand > why they aren't working. > > They might not even find out right away if the trigger only modifies > the columns sometimes so it could be the kind of latent bug that > catches people in production (which wouldn't be improved by the patch > but at least it would produce an error rather than silent data > corruption). > > The only valid use cases that maybe would cause some pain would be > people using the same function for BEFORE *and* AFTER triggers and > where that code is written to just assign to NEW in both cases. That > seems like it would be odd though since we're not talking about an > audit function or something like that if the function is assigning to > NEW... > this behave can be dynamic and it can be active only for AFTER trigger > -- > greg >
