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>
> > yes, but there is minimal agreement of direction of movement. I am not
> > 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
> 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.