Re: procedures and plpgsql PERFORM

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: procedures and plpgsql PERFORM
Date: 2017-12-15 03:43:39
Message-ID: CAFjFpRd5cMyEAAVKNcKR=mQ=1sUkRtG15Ya-uM2zZNNT1Pw2qQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 14, 2017 at 10:16 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
>
> 2017-12-14 17:10 GMT+01:00 David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>:
>>
>> On Thu, Dec 14, 2017 at 8:22 AM, Merlin Moncure <mmoncure(at)gmail(dot)com>
>> wrote:
>>>
>>> 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.
>>>
>>> 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.
>

There is a certain similarly between functions and procedures which
can not be denied, both take IN/OUT arguments and except SELECT/CALL
syntax decoration they are invoked similarly. Just to note: users have
been using function with void return value till now.

If we allow SELECT to be dropped while invoking a function through
PERFORM, why not to drop CALL for procedures similarly?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rushabh Lathia 2017-12-15 03:59:45 Re: [HACKERS] replace GrantObjectType with ObjectType
Previous Message Ashutosh Bapat 2017-12-15 03:37:44 Re: procedures and plpgsql PERFORM