Re: bugfix: BUG #15477: Procedure call with named inout refcursor parameter - "invalid input syntax for type boolean"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bugfix: BUG #15477: Procedure call with named inout refcursor parameter - "invalid input syntax for type boolean"
Date: 2018-11-03 20:47:31
Message-ID: 26116.1541278051@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> pá 2. 11. 2018 v 9:02 odesílatel Peter Eisentraut <
> peter(dot)eisentraut(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas 'ads' Scherbaum 2018-11-03 20:49:38 Re: INSTALL file
Previous Message Ron 2018-11-03 20:06:02 Re: backend crash on DELETE, reproducible locally