At Fri, 24 Apr 2020 16:47:28 +0200, Pavel Stehule <pavel.stehule@gmail.com> wrote in > pá 24. 4. 2020 v 16:07 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal: > > > Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes: > > > On Fri, Apr 24, 2020 at 12:24 PM Pavel Stehule <pavel.stehule@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.
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
