Re: PL/pgSQL 2

On Mon, Sep 1, 2014 at 9:07 PM, Andrew Dunstan [via PostgreSQL] <
ml-node+s1045698n5817265h39(at)n5(dot)nabble(dot)com> wrote:

>
> On 09/01/2014 08:09 PM, Neil Tiffin wrote:
> >
> > That should be enough alone to suggest postgreSQL start working on a
> modern, in core, fast, fully supported language. Of course PL/pgSQL works,
> but so did one-line 5k perl programs that nobody likes today. Everything
> can be done in assembler, but no one suggests that today. Today, it is all
> about programmer productivity. PL/pgSQL has a lot of unnecessary stuff
> that sucks the life out of programmer productivity. And this should be
> very much a concern of the professionals that support PostgreSQL
> >
> > For example:
> >
> > DECLARE
> > declarations
> > BEGIN
> > statements
> > END
> >
> > This looks a lot like COBOL or Pascal, and today is mostly unnecessary.
>
> It looks like Ada, and that's not an accident. (Nor is it a bad thing.)
>
>
> The very last thing we should be doing is to invent a new language.
> There are already plenty to choose from.
>
> cheers
>
> andrew
>
>
​The extent of "plenty" narrows considerably if you factor in a requirement
for SQL to be treated as a first-class construct...

I would welcome the chance to evaluate an unencumbered language designed to
mesh with PostgreSQL​ specifically and that would greatly ease the effort
needed to write applications driven largely via in-database functions. Put
differently - how much effort do we want to making PostgreSQL an
irresistible platform that is difficult to leave? Now, of course, and
salient to the point Andrew made, I'm not sure we actually have anyone with
the talent AND desire to actually create such a language - we haven't need
for a specialist language writer for a while now and I think you'd want a
specialist if you were to try and write a language from scratch (over even
adapt an existing language like what was apparently done with Ada).

The question here is whether the resources are available, if it was deemed
desirable, to even superficially overhaul pl/pgsql?

Random thought as I wrote that: how about considering how pl/pgsql
functionality can be generalize so that it is a database API that another
language can call? In that way the server would drive the core
functionality and the language would simply be an interpreter that enforces
its specific notion of acceptable syntax.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/PL-pgSQL-2-tp5817121p5817267.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.