Re: BUG #18722: Processing arrays with plpgsql raises errors
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2024-11-25T19:16:11Z
Lists: pgsql-bugs
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. regards, tom lane
Commits
-
Fix NULLIF()'s handling of read-write expanded objects.
- 48a6cd1ae636 13.19 landed
- a1168855e0df 14.16 landed
- 97be02ad0015 17.3 landed
- 80cd33bad172 15.11 landed
- 4aba56adcd29 16.7 landed
- 5b8728cd7f9d 18.0 landed