Missing can't-assign-to-constant checks in plpgsql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Missing can't-assign-to-constant checks in plpgsql
Date: 2022-04-28 21:52:09
Message-ID: 214453.1651182729@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

Attachment Content-Type Size
plpgsql-add-missing-checks-for-constant-1.patch text/x-diff 5.3 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2022-04-28 22:11:09 Re: Missing can't-assign-to-constant checks in plpgsql
Previous Message Andrew Dunstan 2022-04-28 19:35:24 Re: json_object returning jsonb reuslt different from returning json, returning text