On Tue, Sep 2, 2014 at 10:27 PM, Merlin Moncure <mmonc...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers