Re: CALL versus procedures with output-only arguments

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> On 04.06.21 23:07, Tom Lane wrote:
>> 0001 is the same patch I posted earlier, 0002 is a delta to enable
>> handling ALTER/DROP per spec.

> I checked these patches. They appear to match what was talked about. I
> didn't find anything surprising. I couldn't apply the 0002 after
> applying 0001 to today's master, so I wasn't able to do more exploratory
> testing. What are these patches based on? Are there are any more open
> issues to focus on?

Hmm, these are atop HEAD from a week or so back. The cfbot seems to
think they still apply. In any case, I was about to spend some effort
on the docs, so I'll post an updated version soon (hopefully today).

> One thing I was wondering is whether we should force CALL arguments in
> direct SQL to be null rather than allowing arbitrary expressions. Since
> there is more elaborate code now to process the CALL arguments, maybe it
> would be easier than before to integrate that.

Yeah. We could possibly do that, but at first glance it seems like it
would be adding code for little purpose except nanny-ism.

One angle that maybe needs discussion is what about CALL in SQL-language
functions. I see that's disallowed right now. If we're willing to keep
it that way until somebody implements local variables a la SQL/PSM,
then we could transition smoothly to having the same definition as in
plpgsql, where you MUST write a variable. If we wanted to open it up
sooner, we'd have to plan on ending with a definition like "write either
a variable, or NULL to discard the value", so that enforcing
must-be-NULL in the interim would make sense to prevent future
surprises. But IMO that would be best done as a SQL-language-function
specific restriction.

I suppose if you imagine that we might someday have variables in
top-level SQL, then the same argument would apply there. But we already
guaranteed ourselves some conversion pain for that scenario with respect
to INOUT parameters, so I doubt that locking down OUT parameters will
help much.

My inclination is to not bother adding the restriction, but it's
only a mild preference.

regards, tom lane