CALL optional in PL/pgSQL

On Wednesday, February 28, 2018, Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:

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

I'm thinking you are thinking of this one.

/messages/by-id/CAFjFpReVcC+RE3WBJb2X1-O=_+ORiZggDZ-Orr0QafeuAC7k-w@mail.gmail.com

David J.

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)

please, fix me, if I am wrong.

SQL/PSM requires it.

I agree, so in this case, the CALL can be optional - because procedures are
called by different mechanism than functions - and there is not additional
overhead. It is not strictly necessary, because tools like ora2pg has not
any problem with procedure identification and some transformations.

But - if we allow optional CALL in PL/pgSQL, then we will have
inconsistence between PL/pgSQL and other environments, when the CALL will
be required. What is not too nice.

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.

I don't like this feature. I don't see any benefit. Different case are
functions - then users can implement some pseudovariables like
CURRENT_USER, ..

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&gt;

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