From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com>, Joel Jacobson <joel(at)trustly(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/pgSQL 2 |
Date: | 2014-09-01 09:53:45 |
Message-ID: | 54044229.5030507@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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Ü
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-09-01 09:58:24 | Re: Make LWLockAcquireCommon() inline? |
Previous Message | Fujii Masao | 2014-09-01 09:52:30 | Re: [Fwd: Re: proposal: new long psql parameter --on-error-stop] |