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.
Pavel
I prefer Merlin's suggestion to just documenting that PERFORM is deprecated and works only with functions - and that to use procedures in pl/pgsql just use the normal SQL CALL command. And to write: "SELECT func()" to invoke functions, again just like one would in an SQL script.