2013/8/29 Pavel Stehule <pavel.steh...@gmail.com> > > > > 2013/8/29 Josh Berkus <j...@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, > ... >
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 >> > >