On Thu, Dec 14, 2017 at 8:22 AM, Merlin Moncure <mmonc...@gmail.com> wrote:
> On Thu, Dec 14, 2017 at 8:38 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Ashutosh Bapat <ashutosh.ba...@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.
