Re: CALL versus procedures with output-only arguments
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-04T19:35:00Z
Lists: pgsql-hackers
On 03.06.21 23:29, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: >> On 02.06.21 02:04, Tom Lane wrote: >>> Hmm, actually we could make step 2 a shade tighter: if a candidate >>> routine is a function, match against proargtypes. If it's a procedure, >>> match against coalesce(proallargtypes, proargtypes). If we find >>> multiple matches, raise ambiguity error. > >> I'm ok with this proposal. > > Cool. Do you want to try to implement it, or shall I? > > A question that maybe we should refer to the RMT is whether it's > too late for this sort of redesign for v14. I dislike reverting > the OUT-procedure feature altogether in v14, but perhaps that's > the sanest way to proceed. I'll take a look at this. I'm not clear on the beta schedule, but the next beta is probably still a few weeks away.
Commits
-
Reconsider the handling of procedure OUT parameters.
- e56bce5d4378 14.0 landed