Re: PL/pgSQL 2

Hi

2014-09-01 11:04 GMT+02:00 Joel Jacobson <joel(at)trustly(dot)com>:

> 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.
>
>
I agree with Andres - it is not a good for plpgsql and for plpgsql users.
The benefit must be significant for 90% of users.

Almost all from your mentioned issue can be solved by some extensions with
some new hooks. I don't agree, so UPDATE/INSERT/DELETE should to work only
with one row.

What I dislike on plpgsql:

* manipulation with expressions
* supply lot of SPI API in plpgsql
* inconsistent internal casting to target / returned values
* missing internal API for more stricter / smarted validation
* strange week implementation of left part of assign statement
* sometimes strange work with composite types
* late IO casting

on second hand it is fast practical language.

Official implementation of plpgsql2 can be very wrong and dangerous signal
- so we should not to do.

My plan .. maybe too long

enhancing SPI to better expression support
new PL API for support variables stack and handling variables
new API with communication with gdb
============================================
implementation of SQL/PSM .. it is new language .. based on relative good
ANSI SQL specification without compatibility issues
reimplementation plpgsql based on new API .. it should to significantly
reduce size

otherwise plpgsql2 is wrong name .. with respect to your goals it should be
"stricter plpgsql"

Regards

Pavel

> Regards, Joel
>
>