On Thu, Dec 14, 2017 at 11:56 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > > 2017-12-14 18:33 GMT+01:00 Merlin Moncure <mmonc...@gmail.com>: >> >> On Thu, Dec 14, 2017 at 10:46 AM, Pavel Stehule <pavel.steh...@gmail.com> >> wrote: >> > >> > >> > 2017-12-14 17:10 GMT+01:00 David G. Johnston >> > <david.g.johns...@gmail.com>: >> >> >> >> On Thu, Dec 14, 2017 at 8:22 AM, Merlin Moncure <mmonc...@gmail.com> >> >> wrote: >> >>> >> >>> On Thu, Dec 14, 2017 at 8:38 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >>> > Ashutosh Bapat <ashutosh.ba...@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() >> > >> > >> > I don't like this idea - functions are not procedures - can be nice if >> > it >> > will be visible. >> >> We need to get rid of PERFORM ASAP. Agree that we need to not obfuscate >> CALL. > > If we have a procedures, then functions without returned values lost a sense > - and I don't see any changes with PERFORM necessary.
I don't think the presence of procedures really changes the thinking here. Having to simulate procedures with void returning functions wasn't really the point; it's an annoying syntax departure from SQL for little benefit other than assuming the users are wrong when they are not explicitly capturing the result.. the topic was heavily discussed: https://www.postgresql.org/message-id/CAHyXU0zYbeT-FzuonaaycbS9Wd8d5JO%2B_niAygzYtv5FMdx4rg%40mail.gmail.com merlin
