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

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

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