Re: Inconsistent trigger behavior between two temporal leftovers
Sergei Patiakin <sergei.patiakin@enterprisedb.com>
From: Sergei Patiakin <sergei.patiakin@enterprisedb.com>
To: Peter Eisentraut <peter@eisentraut.org>,
"Paul A. Jungwirth" <pj@illuminatedcomputing.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2026-04-30T11:02:40Z
Lists: pgsql-hackers
> If you have one, please feel free to add yourself Thanks Paul, I've done that now > Maybe this is not a problem in your patch, but I'm confused under what > circumstances one is supposed to use the return value of > execute_attr_map_slot(). Existing code appears to be inconsistent about > that, but there isn't any explanation anywhere I can see. It looks like `execute_attr_map_slot(attrMap, in_slot, out_slot)` always returns `out_slot`, so assigning the return value to `out_slot` is a no-op. I see a couple of such no-op assignments in the codebase - we could remove them if we think it improves clarity? I don't have any objections to execute_attr_map_slot's interface - it seems conventional for functions that copy/transform a data structure into a caller-passed buffer to also return a pointer to the buffer, e.g. ExecCopySlot, strcpy(3), realpath(3) On Mon, Apr 27, 2026 at 11:40 AM Peter Eisentraut <peter@eisentraut.org> wrote: > > On 08.04.26 14:50, Sergei Patiakin wrote: > > Attaching a patch that makes the behavior more consistent. > > Maybe this is not a problem in your patch, but I'm confused under what > circumstances one is supposed to use the return value of > execute_attr_map_slot(). Existing code appears to be inconsistent about > that, but there isn't any explanation anywhere I can see. >
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix cross-leftover pollution in FOR PORTION OF insert triggers
- 993a7aa0e4af 19 (unreleased) landed