Re: proposal - plpgsql - all plpgsql auto variables should be constant - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal - plpgsql - all plpgsql auto variables should be constant
Date
Msg-id CAFj8pRD+gQhpaRyYx9urOXxC4g20D36iznwz2OehVCvZNGaUEA@mail.gmail.com
Whole thread Raw
In response to Re: proposal - plpgsql - all plpgsql auto variables should beconstant  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers


po 27. 4. 2020 v 5:02 odesílatel Kyotaro Horiguchi <horikyota.ntt@gmail.com> napsal:
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.

There loop parameter is constant


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

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: 2pc leaks fds