Re: procedures and plpgsql PERFORM - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: procedures and plpgsql PERFORM
Date
Msg-id CAFjFpRcGLYmLkzt-o8W+VrS2B6OSxxBCHeP4AtsZw-RALDaxZg@mail.gmail.com
Whole thread Raw
In response to Re: procedures and plpgsql PERFORM  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
On Thu, Dec 14, 2017 at 9:40 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> 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()

Right, that's what I am suggesting.

Furthermore the current error message is misleading:

do $$
begin perform dummy_proc(1); end; $$ language plpgsql;
ERROR:  dummy_proc(integer) is a procedure
LINE 1: SELECT dummy_proc(1)
               ^
HINT:  To call a procedure, use CALL.
QUERY:  SELECT dummy_proc(1)
CONTEXT:  PL/pgSQL function inline_code_block line 2 at PERFORM

The user never wrote SELECT dummy_proc(), it was injected by plpgsql.
Let's assume for a moment, that user infers that s/he has to use CALL
instead. Even then plpgsql doesn't support PERFORM CALL dummy_proc()
or CALL dummy_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.

That would simplify it, but I don't have any opinion as to whether we
should remove PERFORM or not.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: procedures and plpgsql PERFORM
Next
From: Ashutosh Bapat
Date:
Subject: Re: procedures and plpgsql PERFORM