| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| 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-28 22:11:09 | 
| Message-ID: | CAFj8pRA=DQKUz-4yhvtaWGpy0qujoJyySspMZZJ1TeKJeVs86A@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
čt 28. 4. 2022 v 23:52 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
> I happened to notice that there are a couple of places in plpgsql
> that will let you assign a new value to a variable that's marked
> CONSTANT:
>
> * We don't complain if an output parameter in a CALL statement
> is constant.
>
> * We don't complain if a refcursor variable is constant, even
> though OPEN may assign a new value to it.
>
> The attached quick-hack patch closes both of these oversights.
>
> 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
I can implement these checks in plpgsql_check. So possible issues can be
detected and fixed on older versions by using plpgsql_check.
Regards
Pavel
>                         regards, tom lane
>
> PS: I didn't do it here, but I'm kind of tempted to pull out
> all the cursor-related tests in plpgsql.sql and move them to
> a new test file under src/pl/plpgsql/src/sql/.  They look
> pretty self-contained, and I doubt they're worth keeping in
> the core tests.
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2022-04-29 01:30:34 | Re: Re: fix cost subqueryscan wrong parallel cost | 
| Previous Message | Tom Lane | 2022-04-28 21:52:09 | Missing can't-assign-to-constant checks in plpgsql |