On Mon, Sep 1, 2014 at 9:07 PM, Andrew Dunstan [via PostgreSQL] <[hidden email]> 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.