Re: CALL versus procedures with output-only arguments
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
Robert Haas <robertmhaas@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-03T20:50:35Z
Lists: pgsql-hackers
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). 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. regards, tom lane
Commits
-
Reconsider the handling of procedure OUT parameters.
- e56bce5d4378 14.0 landed