From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Missing can't-assign-to-constant checks in plpgsql |
Date: | 2022-04-30 15:57:55 |
Message-ID: | 610683.1651334275@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> čt 28. 4. 2022 v 23:52 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2022-04-30 16:24:02 | Re: pgsql: Add contrib/pg_walinspect. |
Previous Message | Bharath Rupireddy | 2022-04-30 12:49:09 | Re: Switching XLog source from archive to streaming when primary available |