Re: CALL versus procedures with output-only arguments
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-06-10T13:57:15Z
Lists: pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: > On 08.06.21 01:10, Tom Lane wrote: >> Here is said update (rolled up into one patch this time; maybe that will >> avoid the apply problems you had). > This patch looks good to me. Thanks for reviewing! > A minor comment: You changed the docs in some places like this: > - </itemizedlist></para> > + </itemizedlist> > + </para> > The original layout is required to avoid spurious whitespace in the > output (mainly affecting man pages). Ugh, that seems like a toolchain bug. We're certainly not consistent about formatting things that way. But I'll refrain from changing these. >> I noticed that there is one other loose end in the patch: should >> LookupFuncName() really be passing OBJECT_ROUTINE to >> LookupFuncNameInternal()? > It appears that all uses of LookupFuncName() are lookups of internal > support functions (with one exception in pltcl), so using > OBJECT_FUNCTION would be okay. OK, I'll take a closer look at that. > It might be good to keep the argument order of LookupFuncNameInternal() > consistent with LookupFuncWithArgs() with respect to the new ObjectType > argument. Good point, thanks. regards, tom lane
Commits
-
Reconsider the handling of procedure OUT parameters.
- e56bce5d4378 14.0 landed