2014-09-03 7:23 GMT+02:00 Joel Jacobson <j...@trustly.com>: > On Wed, Sep 3, 2014 at 7:17 AM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > yes, but there is minimal agreement of direction of movement. I am not > alone > > who are thinking so your proposal is not good for general usage. > > Minimal agreement? That's not true. The other group of users have been > discussing > a completely new language, which is a different discussion than the > one on PL/pgSQL 2. > > Just because you think a new language is what we need, doesn't mean > you automatically > would think it's not a good idea to improve PL/pgSQL and create PL/pgSQL 2. >
I am not against to improve a PL/pgSQL. And I repeat, what can be done and can be done early: a) ASSERT clause -- with some other modification to allow better static analyze of DML statements, and enforces checks in runtime. b) #option or PRAGMA clause with GUC with function scope that enforce check on processed rows after any DML statement c) maybe introduction automatic variable ROW_COUNT as shortcut for GET DIAGNOSTICS rc = ROW_COUNT If you need more, and some users would more, then it job for new language really. But there are more questions: * what will be base for this language? (for one group people any ALGOL like languages are obsolete and anything what is not HASKELL (or what has not enough obscure syntax) is not enough modern. I propose a SQL/PSM -- but it cannot be enough modern for these people - it is ALGOL like (Modula), it has strong difference between dynamic and embedded SQL. Some people will propose T-SQL, other PL/SQL. It is really valid question. My opinion is, so it is not community task - it is good research project, but not community, because can be terrible hard to find any consensus in this area. * what will be engine for this languge? PLpgSQL engine is mature and some from your proposal can be implemented simply, but probably very early you can find a limits. For example change of typing system needs rewriting 30% code (or if you would to implement together with current plpgsql 20% new code). Lot of expectation from new language (like speedup of expression evaluation or more dynamical access to variables, record fields) is terrible to build on current engine. Regards Pavel
