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