Re: PL/pgSQL PERFORM with CTE - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: PL/pgSQL PERFORM with CTE
Date
Msg-id CAFj8pRAMmFL8=9q=-AvANkKoyTVomX3yvoqhKuSxw_ad-g-oEw@mail.gmail.com
Whole thread Raw
In response to Re: PL/pgSQL PERFORM with CTE  (Josh Berkus <josh@agliodbs.com>)
Responses Re: PL/pgSQL PERFORM with CTE  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers



2013/8/29 Josh Berkus <josh@agliodbs.com>
On 08/29/2013 02:22 PM, Pavel Stehule wrote:
> Still I don't think so correct solution is enabling a unbound SELECTs, but
> correct is a fix a PERFORM and remove a necessity to use a PERFORM for call
> of VOID functions.

You have yet to supply any arguments which support this position.

Several people have pointed out that requiring PERFORM needlessly makes
life hard for PL/pgSQL programmers, especially new ones.  You have not
given us any benefit it supplies in return.

And no, I don't accept the idea that we might someday have some kind of
conflicting syntax for stored procedures which nobody is working on as a
valid argument.

The more stronger argument is not allow a useless execution.

PL/pgSQL is a verbose language and it is based on very strict ADA language - a few a secure mechanism we dropped (and some from good reasons).

So questions is - how much we would to go against a ADA ideas and PL/SQL rules.

No think so PERFORM is a significant problem. A mayor problem for beginners is usually a fact, so PL/pgSQL is ALGOL like languages - and they don't know with these languages. Second problem is missing a more dynamic data structures. Next a really different syntax and usage of OUT variables, ...

Regards

Pavel
 

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: PL/pgSQL PERFORM with CTE
Next
From: "David E. Wheeler"
Date:
Subject: Re: PL/pgSQL PERFORM with CTE