> 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.
>
