Thread: CALL optional in PL/pgSQL

This seems to be a popular issue when porting from PL/SQL, so I'll throw
it out here for discussion.  Apparently, in PL/SQL you can call another
procedure without the CALL keyword.  Here is a patch that attempts to
implement that in PL/pgSQL as well.  It's not very pretty.

I seem to recall that there were past discussions about this, with
respect to the PERFORM command, but I couldn't find them anymore.

Also, I think PL/SQL allows you to call a procedure with no arguments
without parentheses.  I have not implemented that.  I think it could be
done, but it's not very appealing.

If anyone has more details about the PL/SQL side of this, that would be
useful.  What I could find is that using CALL and not using CALL appear
to be equivalent.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

I seem to recall that there were past discussions about this, with
respect to the PERFORM command, but I couldn't find them anymore.

Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2018-03-01 5:51 GMT+01:00 Peter Eisentraut <peter.eisentraut@2ndquadrant.com
>> This seems to be a popular issue when porting from PL/SQL, so I'll throw
>> it out here for discussion.  Apparently, in PL/SQL you can call another
>> procedure without the CALL keyword.  Here is a patch that attempts to
>> implement that in PL/pgSQL as well.  It's not very pretty.

> The CALL is not optional in PL/SQL - I was surprised - it is required in
> some environments, and it should not be used in other (like PL/SQL)

I think this is an actively bad idea.  It introduces an inherent ambiguity
into the grammar; for instance

    PERFORM (2);

now has two valid interpretations.  The only way to resolve that is with
heuristics or treating a bunch more words as reserved keywords, neither of
which are appetizing.  (I didn't look to see which way Peter did it, but
his description of his patch as "not very pretty" doesn't fill me with
happiness.)  And it would likely cause headaches down the road whenever
we attempt to add new syntax to plpgsql.

I think we should reject the idea.

>> Also, I think PL/SQL allows you to call a procedure with no arguments
>> without parentheses.  I have not implemented that.  I think it could be
>> done, but it's not very appealing.

> I don't like this feature.

This idea is even worse in terms of the amount of syntax space it will
occupy, again for zero functional benefit.

            regards, tom lane

On Fri, Mar 2, 2018 at 2:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2018-03-01 5:51 GMT+01:00 Peter Eisentraut <peter.eisentraut@2ndquadrant.com
>>> This seems to be a popular issue when porting from PL/SQL, so I'll throw
>>> it out here for discussion.  Apparently, in PL/SQL you can call another
>>> procedure without the CALL keyword.  Here is a patch that attempts to
>>> implement that in PL/pgSQL as well.  It's not very pretty.
>
>> The CALL is not optional in PL/SQL - I was surprised - it is required in
>> some environments, and it should not be used in other (like PL/SQL)


It's not required in a PL/SQLl block, see
<https://www.tutorialspoint.com/plsql/plsql_procedures.htm>

This is hardly surprising given PL/SQL's Ada roots. This is exactly
how Ada allows procedure calls.


>
> I think this is an actively bad idea.  It introduces an inherent ambiguity
> into the grammar; for instance
>
>         PERFORM (2);
>
> now has two valid interpretations.  The only way to resolve that is with
> heuristics or treating a bunch more words as reserved keywords, neither of
> which are appetizing.  (I didn't look to see which way Peter did it, but
> his description of his patch as "not very pretty" doesn't fill me with
> happiness.)  And it would likely cause headaches down the road whenever
> we attempt to add new syntax to plpgsql.
>
> I think we should reject the idea.


Well, the upside would be increased Oracle compatibility. I don't
think that's worthless.

I haven't dug deeply into it, but Peter's patch didn't look
desperately ugly to me at first glance.

Even though it's a tiny patch this seems like next release material at best.

>
>>> Also, I think PL/SQL allows you to call a procedure with no arguments
>>> without parentheses.  I have not implemented that.  I think it could be
>>> done, but it's not very appealing.
>
>> I don't like this feature.
>
> This idea is even worse in terms of the amount of syntax space it will
> occupy, again for zero functional benefit.
>

If we were going to do it then we should be consistent about it and
also allow parameter-less function calls to skip the parentheses. But
anyway none of that is currently proposed so let's save the argument
for the time when it is :-)

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 27/03/18 03:00, Andrew Dunstan wrote:
> On Fri, Mar 2, 2018 at 2:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think this is an actively bad idea.  It introduces an inherent ambiguity
>> into the grammar; for instance
>>
>>          PERFORM (2);
>>
>> now has two valid interpretations.  The only way to resolve that is with
>> heuristics or treating a bunch more words as reserved keywords, neither of
>> which are appetizing.  (I didn't look to see which way Peter did it, but
>> his description of his patch as "not very pretty" doesn't fill me with
>> happiness.)  And it would likely cause headaches down the road whenever
>> we attempt to add new syntax to plpgsql.
>>
>> I think we should reject the idea.
> 
> Well, the upside would be increased Oracle compatibility. I don't
> think that's worthless.
> 
> I haven't dug deeply into it, but Peter's patch didn't look
> desperately ugly to me at first glance.

I don't much like this either. The ambiguity it introduces in the 
grammar is bad. I'll mark this as rejected in the commitfest.

- Heikki