| 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 21:47:04 |
| Message-ID: | 28551.1541281624@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> I'm going to go see about converting this to just call
> expand_function_arguments and then drop all the special-case code.
So while looking at that ... isn't the behavior for non-writable output
parameters basically insane? It certainly fails to accord with the
plpgsql documentation, which shows an example that would throw an error:
CREATE PROCEDURE triple(INOUT x int)
...
CALL triple(5);
It's even weirder that you can get away with not supplying a writable
target value for an output argument so long as it has a default.
I think the behavior here ought to be "if the actual argument is a plpgsql
variable, assign the output back to it, otherwise do nothing". That's
much closer to the behavior of OUT arguments in other old-school
programming languages.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-11-03 21:55:15 | Reduce maintenance burden of alternative output files with \if \quit |
| Previous Message | Andreas 'ads' Scherbaum | 2018-11-03 21:17:54 | Re: [PATCH] Improvements to "Getting started" tutorial for Google Code-in task |