From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Stehule <pavel.stehule@gmail.com>
cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Missing can't-assign-to-constant checks in plpgsql
In-reply-to: <CAFj8pRA=DQKUz-4yhvtaWGpy0qujoJyySspMZZJ1TeKJeVs86A@mail.gmail.com>
References: <214453.1651182729@sss.pgh.pa.us> <CAFj8pRA=DQKUz-4yhvtaWGpy0qujoJyySspMZZJ1TeKJeVs86A@mail.gmail.com>
Comments: In-reply-to Pavel Stehule <pavel.stehule@gmail.com>
	message dated "Fri, 29 Apr 2022 00:11:09 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <610682.1651334275.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Sat, 30 Apr 2022 11:57:55 -0400
Message-ID: <610683.1651334275@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/610683.1651334275%40sss.pgh.pa.us>
Precedence: bulk

Pavel Stehule <pavel.stehule@gmail.com> writes:
> čt 28. 4. 2022 v 23:52 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
>> Perhaps the OPEN change is a little too aggressive, since if
>> you give the refcursor variable some non-null initial value,
>> OPEN won't change it; in that usage a CONSTANT marking could
>> be allowed.  But I really seriously doubt that anybody out
>> there is marking such variables as constants, so I thought
>> throwing the error at compile time was better than postponing
>> it to runtime so we could handle that.
>> 
>> Regardless of which way we handle that point, I'm inclined to
>> change this only in HEAD.  Probably people wouldn't thank us
>> for making the back branches more strict.

> +1

After sleeping on it, I got cold feet about breaking arguably
legal code, so I made OPEN check at runtime instead.  Which
was probably a good thing anyway, because it made me notice
that exec_stmt_forc() needed a check too.  AFAICS there are no
other places in pl_exec.c that are performing assignments to
variables not checked at parse time.

Pushed that way.

			regards, tom lane