po 27. 4. 2020 v 5:02 odesílatel Kyotaro Horiguchi <horikyota....@gmail.com> napsal:
> At Fri, 24 Apr 2020 16:47:28 +0200, Pavel Stehule <pavel.steh...@gmail.com> > wrote in > > pá 24. 4. 2020 v 16:07 odesílatel Tom Lane <t...@sss.pgh.pa.us> napsal: > > > > > Ashutosh Bapat <ashutosh.bapat....@gmail.com> writes: > > > > On Fri, Apr 24, 2020 at 12:24 PM Pavel Stehule < > pavel.steh...@gmail.com> > > > wrote: > > > >> plpgsql generate lot of auto variables - FOUND, SQLERRM, cycle's > > > control variable, TG_WHEN, TG_OP, .. > > > >> Currently these variables are not protected, what can be source of > > > problems, mainly for not experienced users. I propose mark these > variables > > > as constant. > > > > > > > +1 for general idea. > > > > > > 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. > > > > > > > This is not black/white issue. Maybe can sense to modify the FOUND > > variable, but modification of control variable has not any sense. The > > updated value is rewriten by runtime any iteration. You cannot to use > > modification of control variable to skip some iterations like in C. > > It seems to me, the loop structure is not a parallel of for() in C. It > is rather a parallel of foreach of Perl or "for in range()" in > Python. So it is natural to me that the i is assignable and reset with > the next value at every iteration. I believe that there are many > existing cases where the control variable is modified in a loop. > it is based on PL/SQL language and this language is based on ADA. There loop parameter is constant https://www.adaic.org/resources/add_content/standards/05aarm/html/AA-5-5.html Regards Pavel > On the other hand, I'm not sure about FOUND and the similars and I > don't have a firm opinion them. I don't see a use case where they need > to be assignable. However, I don't see a clear reason they mustn't be > assignable, too. (And the behavior is documented at least for FOUND.) > > > > 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. > > > > > > > For before triggers the NEW have to be updated. Any other maybe should be > > protected, but there is little bit different kind of informations. > > > > > In short, -1. This ship sailed about twenty years ago. > > regards. > > -- > Kyotaro Horiguchi > NTT Open Source Software Center >
