From: | Joel Jacobson <joel(at)trustly(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/pgSQL 2 |
Date: | 2014-09-02 21:21:50 |
Message-ID: | CAASwCXfuy384ic_pSUM3E2-N01n0ot=-KVAnjJOq_fP1JPMA-w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 2, 2014 at 10:27 PM, Merlin Moncure <mmoncure(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2014-09-02 21:23:26 | Re: PL/pgSQL 2 |
Previous Message | Tom Lane | 2014-09-02 21:21:03 | Re: Escaping from blocked send() reprised. |