Re: CALL versus procedures with output-only arguments
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
Robert Haas <robertmhaas@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-03T21:22:09Z
Lists: pgsql-hackers
On 6/3/21 4:50 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> Not sure I follow the "other datatypes" bit. Are you saying the spec >> won't let you have this?: >> create procedure divide(x int, y int, OUT q int); >> create procedure divide(x int, y int, OUT q float); > In fact it won't, because the spec's rule is simply "you can't have > two procedures with the same name and same number of parameters" > (where they count OUT parameters, I believe). Oh. That's a truly awful rule. > However the case > I was considering was wanting to have > > create procedure divide(x int, y int, OUT q int) ... > create procedure divide(x numeric, y numeric, OUT q numeric) ... > > which likewise falls foul of the spec's restriction, but which > IMO must be allowed in Postgres. > Right, we should certainly allow that. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Commits
-
Reconsider the handling of procedure OUT parameters.
- e56bce5d4378 14.0 landed