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.
