Remove redundant code in pl_exec.c
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t46583psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 11:15 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t46583_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t46583_1 && git checkout t46583_1Patchset v1 (message #1) is on t46583_1
Hi, hackers
I found there are some redundant code in pl_exec.c,
plpgsql_param_eval_generic_ro is same as plpgsql_param_eval_generic
except it invokes MakeExpandedObjectReadOnly.
IMO, we can invoke plpgsql_param_eval_generic in plpgsql_param_eval_generic_ro
to avoid the redundant.
Is there something I missed? Any thoughts?
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
Japin Li <japinli@hotmail.com> writes:
I found there are some redundant code in pl_exec.c,
plpgsql_param_eval_generic_ro is same as plpgsql_param_eval_generic
except it invokes MakeExpandedObjectReadOnly.
Which is exactly why it's NOT redundant.
IMO, we can invoke plpgsql_param_eval_generic in plpgsql_param_eval_generic_ro
to avoid the redundant.
I don't like this particularly --- it puts way too much premium on
the happenstance that the MakeExpandedObjectReadOnly call is the
very last step in the callback function. If that needed to change,
we'd have a mess.
regards, tom lane
On Fri, 09 Sep 2022 at 23:34, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Japin Li <japinli@hotmail.com> writes:
IMO, we can invoke plpgsql_param_eval_generic in plpgsql_param_eval_generic_ro
to avoid the redundant.I don't like this particularly --- it puts way too much premium on
the happenstance that the MakeExpandedObjectReadOnly call is the
very last step in the callback function. If that needed to change,
we'd have a mess.
Sorry, I don't get your mind. Could you explain it more? Thanks in advance!
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
Japin Li <japinli@hotmail.com> writes:
On Fri, 09 Sep 2022 at 23:34, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I don't like this particularly --- it puts way too much premium on
the happenstance that the MakeExpandedObjectReadOnly call is the
very last step in the callback function. If that needed to change,
we'd have a mess.
Sorry, I don't get your mind. Could you explain it more? Thanks in advance!
This refactoring cannot support the situation where there is more
code to execute after MakeExpandedObjectReadOnly.
regards, tom lane