Re: PL/pgSQL PERFORM with CTE

2013/8/29 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>

>
>
>
> 2013/8/29 Josh Berkus <josh(at)agliodbs(dot)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,
> ...
>

look to stackoverflow for often questions - the big issue is impossibility
to iterate over record -- and return really dynamic result - pivot tables.

Regards

Pavel

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