Re: PL/pgSQL 2

On 09/01/2014 11:24 AM, Andres Freund wrote:
> On 2014-09-01 11:04:53 +0200, Joel Jacobson wrote:
>> 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
> -many.
>
> Look at the *disaster* the few minor changes in python3 were. It's now,
> years after, only starting to get used again.
>
> You're going to have to find a more gradual way of doing this.
Probably a better way (and there has been some talk of it) is
having some kind of PRAGMA functionality, or pl/pgsql specific
LOCAL SET to affect "just this function" and not spill to nested
functions as is the case for SETs now.


Cheers

-- 
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ