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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal - plpgsql - all plpgsql auto variables should be constant
Date: 2020-04-27 04:56:13
Message-ID: CAFj8pRD+gQhpaRyYx9urOXxC4g20D36iznwz2OehVCvZNGaUEA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

po 27. 4. 2020 v 5:02 odesílatel Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
napsal:

> 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.
>

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
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-04-27 05:11:06 Re: 2pc leaks fds
Previous Message David Rowley 2020-04-27 03:44:35 Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays