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.
I think OP is simply misunderstanding the docs. In pl/pgsql, a leading keyword (SELECT/PERFORM/CALL/etc) is *required*. For example, you can't do this: <snip> BEGIN a := 1; f(); -- illegal PERFORM f(); -- ok b := f(); -- ok ... <snip> What the documentation is trying to say is that you can do INSERT/UPDATE/etc without any extra decoration and no special handling as with PERFORM. Another way of stating that is SQL commands are 'first class' in pl/pgsql, in that they can be inserted without any pl/pgsql handling. 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). If so done, that entire section of language in the docs would be moot since SELECT wouldn't really be any different in pl/pgsql than say, INSERT from a syntax perspective. All SQL commands, except for those that we've reserve to be not usable in functions/procedures would operate similarly 'in-procedure' vs 'not-in-'procedure', which is a good thing IMO. This thread is yet another example of why the SELECT/PERFORM dichotomy just confuses people. merlin
