Re: procedures and plpgsql PERFORM

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 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.

David J.