PL/pgSQL 2 - Mailing list pgsql-hackers
| From | Joel Jacobson |
|---|---|
| Subject | PL/pgSQL 2 |
| Date | |
| Msg-id | CAASwCXchFh_SOrMtteQszoNnhQdU9v-QysUQ5ToFBEcLrw4F-Q@mail.gmail.com Whole thread Raw |
| Responses |
Re: PL/pgSQL 2
Re: PL/pgSQL 2 Re: PL/pgSQL 2 Re: PL/pgSQL 2 Re: PL/pgSQL 2 Re: PL/pgSQL 2 Re: PL/pgSQL 2 Re: PL/pgSQL 2 Re: PL/pgSQL 2 |
| List | pgsql-hackers |
Hi,
For those of you who use PL/pgSQL every day, I'm quite certain you all feel there are a number of things you would like to change in the language, but realize it cannot be achieved without possibly breaking compatibility, at least in theory. Even though you own code would survive the change, there might be code somewhere in the world which would break. This is of course not acceptable and that's why we have the current status quo of development, or at least not far away from a status quo.
So instead of continue to adding optional settings to the config file, and instead of killing discussions around what can be done by bringing up the backwards-compatibility argument, let's instead fork the language and call it plpgsql2. Since no code is yet written in plpgsql2, we can start of from a clean sheet, and no good ideas need to be killed due to backwards-compatibility concerns.
The interest for such a project is probably limited to a small number of companies/people around the world, as most users are probably perfectly happy with the current version of plpgsql, as they only use it occasionally and not every day like we do at my company.
Just like with plpgsql, once released, plpgsql2 cannot break compatibility with future versions, so we only have one chance to carefully think though what we would like to change in the language.
From the top of my head, these are Things I personally would want to see in plpgsql2:
+ Make UPDATE/INSERT/DELETE throw error if they didnt' modify exactly 1 row, as that's the most common use-case, and provide alternative syntax to modify multiple or zero rows.
+ 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.
+ Change all warnings into errors
These are small changes, probably possible with just a few hundred lines of code in total, which also should be the ambition, as larger changes would never survive during time as it would require too much efforts to keep up with the main project. Secondly, I trust plpgsql mainly because it's being used by a lot of people in a lot of production systems, the same would not hold true for plpgsql2 for the first years of existence, so we who would use it in production systems must understand every single line of code changed and feel the risk of possible bugs and their impact are within acceptable boundaries.
I can probably think of a few more things, but these are the major annoyances.
Please share your wish list of things you would want in plpgsql2 which are not possible to implement in plpgsql because they could possibly break compatibility.
Regards, Joel
pgsql-hackers by date: