Re: Missing can't-assign-to-constant checks in plpgsql
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-30T15:57:55Z
Lists: pgsql-hackers
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
Commits
-
Tighten enforcement of variable CONSTANT markings in plpgsql.
- ccd10a9bfa54 15.0 landed