2017-12-14 17:10 GMT+01:00 David G. Johnston <david.g.johns...@gmail.com>:
> 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 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. > > David J. >
