> > > 2017-12-14 17:10 GMT+01:00 David G. Johnston <david.g.johnston@gmail.com>: >> >> On Thu, Dec 14, 2017 at 8:22 AM, Merlin Moncure <mmoncure@gmail.com> >> wrote: >>> >>> On Thu, Dec 14, 2017 at 8:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> > Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes: >>> >> We allow a function to be invoked as part of PERFORM statement in >>> >> plpgsql >>> >> ... >>> >> But we do not allow a procedure to be invoked this way >>> > >>> >> Procedures fit that category and like functions, I think, we should >>> >> allow them be invoked directly without any quoting and CALL >>> >> decoration. >>> > >>> > How is that going to work? What if the procedure tries to commit the >>> > current transaction? >>> > >>> > IOW, this is not merely a syntactic-sugar question. >>> >>> BTW, We've already come to (near-but good enough) consensus that >>> PERFORM syntax is really just unnecessary, and I submitted a patch to >>> make it optional (which I really need to dust off and complete). >> >> >> Except right now PERFORM doesn't exist in SQL and is a pl/pgsql keyword to >> specify a specific limited form of the SQL SELECT command. CALL is an SQL >> command. I don't see any real upside to allowing pl/pgsql to accept >> omission of the command tag while SQL cannot - at least not without a >> use-case describe why such syntax would be beneficial. And likely those use >> cases would revolve around some looping variant as opposed to a single >> stand-alone, result-less, CALL. >> >> If we do keep "PERFORM" in the pl/pgsql vocab I'd consider the following >> enhancement: >> PERFORM func() => SELECT func() >> PERFORM proc() => CALL proc() > >
> I don't like this idea - functions are not procedures - can be nice if it > will be visible. >
There is a certain similarly between functions and procedures which can not be denied, both take IN/OUT arguments and except SELECT/CALL syntax decoration they are invoked similarly. Just to note: users have been using function with void return value till now.
No, there are significant difference between SELECT and CALL - procedure is not a void function.
If we allow SELECT to be dropped while invoking a function through PERFORM, why not to drop CALL for procedures similarly?
From my perspective a PERFORM is not bad idea, because it is consistent in PLpgSQL.
Again - I don't see more issues related to PERFORM - usually much more terrible is different system for OUT variables. This is a problem.
Regards
Pavel
-- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
