Re: BUG #18722: Processing arrays with plpgsql raises errors
От | Dean Rasheed |
---|---|
Тема | Re: BUG #18722: Processing arrays with plpgsql raises errors |
Дата | |
Msg-id | CAEZATCXZvn62enX=vYiosOFDT=ya4j-6vhaw7xw8Kb18d6+v5Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18722: Processing arrays with plpgsql raises errors (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Mon, 25 Nov 2024 at 19:16, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Dean Rasheed <dean.a.rasheed@gmail.com> writes: > > I didn't mean do it in all cases, I just meant the NullIfExpr case > > identified here. My point was that instead of modifying the evaluation > > code for EEOP_NULLIF to make it call > > MakeExpandedObjectReadOnlyInternal(), it would be easier to insert a > > EEOP_MAKE_READONLY step for the first argument of the EEOP_NULLIF > > step. > > But then the NULLIF step would only have access to the R/O pointer, > no? We do want to pass on a R/W pointer to the output, if we got > one, to handle cases like > fconsumer(NULLIF(fproducer(...), ...), ...) > Admittedly that's a pretty edgy edge-case, but still we're leaving > money on the table if we don't do it. So I think we have to deal > with the issue within NULLIF. > OK, that makes sense. Regards, Dean
В списке pgsql-bugs по дате отправления: