Re: proposal - plpgsql - all plpgsql auto variables should be constant

po 27. 4. 2020 v 16:26 odesílatel Greg Stark <stark(at)mit(dot)edu> napsal:

> On Fri, 24 Apr 2020 at 10:08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>