From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(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 05:06:09 |
Message-ID: | CAFj8pRCF4p4W7DnN7TYRVJGbFHM0NcTSmJbjQ+19_5wz0CydxQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2017-12-15 4:43 GMT+01:00 Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>:
> 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.
>
No, there are significant difference between SELECT and CALL - procedure is
not a void function.
> If we allow SELECT to be dropped while invoking a function through
> PERFORM, why not to drop CALL for procedures similarly?
>
From my perspective a PERFORM is not bad idea, because it is consistent in
PLpgSQL.
Again - I don't see more issues related to PERFORM - usually much more
terrible is different system for OUT variables. This is a problem.
Regards
Pavel
>
> --
> Best Wishes,
> Ashutosh Bapat
> EnterpriseDB Corporation
> The Postgres Database Company
>
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2017-12-15 05:51:03 | Re: [HACKERS] Partition-wise aggregation/grouping |
Previous Message | Rushabh Lathia | 2017-12-15 03:59:45 | Re: [HACKERS] replace GrantObjectType with ObjectType |