Re: procedures and plpgsql PERFORM

On Thu, Dec 14, 2017 at 8:38 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)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