Re: PL/pgSQL 2 - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: PL/pgSQL 2
Date
Msg-id CAFj8pRBxpW0pfG-RVkaJzTbDNZrmzxXeZ7iMyU7T4EvWmqjB2g@mail.gmail.com
Whole thread Raw
In response to Re: PL/pgSQL 2  (Joel Jacobson <joel@trustly.com>)
Responses Re: PL/pgSQL 2
Re: PL/pgSQL 2
List pgsql-hackers



2014-09-03 7:23 GMT+02:00 Joel Jacobson <joel@trustly.com>:
On Wed, Sep 3, 2014 at 7:17 AM, Pavel Stehule <pavel.stehule@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

 

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Patch for psql History Display on MacOSX
Next
From: Szymon Guz
Date:
Subject: Re: PL/pgSQL 2