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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(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-24 14:07:17
Message-ID: 22622.1587737237@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

In short, -1. This ship sailed about twenty years ago.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-04-24 14:19:23 Re: Binary COPY IN size reduction
Previous Message James Coleman 2020-04-24 13:38:54 Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays