Re: PL/pgSQL 2

On Tue, Sep 2, 2014 at 10:27 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> What is the reasoning for breaking compatibiilty?  Why not improve the
> language that's there?

Because many suggested improvement are not possible without
breaking compatibility, at least in theory. See previous posts in the thread.

> where I would have had to so for computation reasons.  If you *must*
> process things row by row, why not use the facility in the language
> that handle that: "WHERE CURRENT OF".

Again, because I use PL/pgSQL functions for *all* data access,
which means I don't have any prepared statements updating single rows
from my application code outside the database, as my PL/pgSQL code
*is* my application and I don't have any direct table access from outside
the database and my PL/pgSQL functions.

That means even something as simple as updating some column(s) in a table
matching the primary key, is done inside a PL/pgSQL function.

>
>> + Make SELECT .. INTO .. throw an error if it selects more than 1 row. INTO
>> STRICT only works if no rows should be an error, but there is currently no
>> nice way if no rows OR exactly 1 row should be found by the query.
>
> I see the point here, but this is not a fundamental problem with the
> language IMO.

Yes it is a language problem. Show me how to do it in a nice way with PL/pgSQL?
It cannot be done.

>> + Change all warnings into errors
>
> This is an ok idea, but not sure why you have to re-invent pl/pgsql to do it.

> Here are the headaches I see:
>
> * performance: plpsql can be slow for many types of iterative
> processing.  everybody wants the language to run faster but rewriting
> from scratch doesn't seem a good way to do that unless the current
> language structure has some critical performance blocking shortcoming.

Performance is always nice, but that won't require a new language though.

> * lack of non-table data structures (like hashmap, etc).  At present
> pl/plgsql only has arrays to manage temporary non-table data.  this is
> where plpgsql is bad but many of the other languages like pl/v8 etc
> are good.

+1. I've missed hashmaps sometimes. I usually resort to temp tables.