| From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18722: Processing arrays with plpgsql raises errors |
| Date: | 2024-11-25 10:30:23 |
| Message-ID: | CAEZATCWKt=XKP12qZhqBX4JaVSatmFwYFnoGYEDDqCbpe-HrEA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Sun, 24 Nov 2024 at 22:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Here's a fleshed-out patch with a test case and JIT support. This
> is about the first time I've messed with LLVM, so I wouldn't mind
> some review of what I did in llvmjit_expr.c. In particular, do I
> correctly understand that "l_funcvalue(b, v_fcinfo, 0)" produces
> a reference to a copy of the initial value of args[0].value?
>
I don't know about that, but I wonder if this bug could be fixed by
having ExecInitExprRec() insert a EEOP_MAKE_READONLY step. Then it
wouldn't be necessary to make any changes to the expression evaluation
code.
Regards,
Dean
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2024-11-25 12:26:52 | BUG #18724: High data disk utilization during log writing |
| Previous Message | Thomas Munro | 2024-11-25 10:01:54 | Re: Build failure with GCC 15 (defaults to -std=gnu23) |