Re: CALL versus procedures with output-only arguments

On 04.06.21 23:07, Tom Lane wrote:
> I wrote:
>> It would likely not be very hard to fix pg_dump to include explicit
>> IN markers.  I don't think this results in a compatibility problem
>> for existing dumps, since they won't be taken from databases in
>> which there are procedures with OUT arguments.
> 
> Actually, all we have to do to fix pg_dump is to tweak ruleutils.c
> (although this has some effects on existing regression test outputs,
> of course).  So maybe it's not as bad as all that.
> 
> Here's a draft-quality patch to handle ALTER/DROP this way.  I think
> the code may be finished, but I've not looked at the docs at all.
> 
> 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?

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.