Re: merging some features from plpgsql2 project

2016-12-28 19:23 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> On 12/28/16 12:15 PM, Pavel Stehule wrote:
>
>> GUC are fragile - the source code and settings can be separated.
>>
>
> *Can* be, but they don't *have* to be. That's a huge feature, not a bug.
>
> Our #option is more robust, because source code holds all flags required
>> for execution. So I would to see a mechanism, that will be strongly
>> joined with code.
>>
>
> That means you must ALWAYS specify, which is an enormous pain. It
> basically guarantees that users will NEVER switch to the new syntax.
>
> Using function assigned GUC is similar, but it is looking less robust -
>> and some editors can forgot this information.
>>
>
> If you forget then you get an error. Then you remember.
>
> Lot of issues we can solved by plpgsq.extra_error, extra_warnings - but
>> probably not all - for example issue of FOUND variable or introducing
>> new auto variable ROW_COUNT. PLpgSQL - PL/SQL is safe - it propose the
>> statement GET DIAGNOSTICS, but I understand so isn't funny to write more
>> and more GET DIAGNOSTICS rc = ROW_COUNT; So some shortcuts can be nice,
>> but there is risk, so this shortcut breaks existing code, and the
>> costs/benefits are individual. There cannot be 100% agreement ever. So
>> some customisation should be good.
>>
>
> That's the whole point of having settings to deal with incompatibilities:
> so we can actually fix these warts without breaking everyone's code, yet
> also make it clear to users that they should stop using the warts and
> instead use the new and improved syntax.

Now, the incompatibility can be hard issue - it is big question if we lock
some users on old versions because some users can save to lines of code.
Introduction of ROW_COUNT is lowly incompatibility - it can be simply
detected - but for example change of behave of FOUND variable is terrible,
because the code will be quietly calculate differently. sometimes we can
break code - probably people will not be happy, but sometimes we can change
the results - it can be big fail. So on one side is big costs. On second
side is few lines less code.

Regards

Pavel

>
> --
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> Experts in Analytics, Data Architecture and PostgreSQL
> Data in Trouble? Get it in Treble! http://BlueTreble.com
> 855-TREBLE2 (855-873-2532)
>