Re: PL/pgSQL PERFORM with CTE
| От | Pavel Stehule |
|---|---|
| Тема | Re: PL/pgSQL PERFORM with CTE |
| Дата | |
| Msg-id | CAFj8pRAMmFL8=9q=-AvANkKoyTVomX3yvoqhKuSxw_ad-g-oEw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: PL/pgSQL PERFORM with CTE (Josh Berkus <josh@agliodbs.com>) |
| Ответы |
Re: PL/pgSQL PERFORM with CTE
|
| Список | pgsql-hackers |
2013/8/29 Josh Berkus <josh@agliodbs.com>
On 08/29/2013 02:22 PM, Pavel Stehule wrote:You have yet to supply any arguments which support this position.
> 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.
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
Pavel
В списке pgsql-hackers по дате отправления: