Pavel Stehule <pavel.stehule@gmail.com> writes:
> pá 2. 11. 2018 v 9:02 odesílatel Peter Eisentraut <
> peter.eisentraut@2ndquadrant.com> napsal:
>> Could you explain your analysis of the problem and how this patch
>> proposes to fix it?
> The original code works with original function arguments - and this compare
> with argmodes fields. But when you use named args, this expectation is not
> valid.
Yeah. IMO, the fundamental mistake in this code was to try to avoid
calling expand_function_arguments. The proposed patch still tries to
avoid that, which is why it's still a mess and, I suspect, still fails
on args with default values. You cannot process calls with named args
correctly without accounting for defaults.
I'm going to go see about converting this to just call
expand_function_arguments and then drop all the special-case code.
BTW, it looks to me like ExecuteCallStmt trashes the passed-in CallStmt
in cases where expand_function_arguments is not a no-op. Is that
really safe? Seems to me it'd cause problems if, for example, dealing
with a CallStmt that's part of a prepared stmt or cached plan.
regards, tom lane
