Re: merging some features from plpgsql2 project

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

> On 12/28/16 7:16 AM, Pavel Stehule wrote:
>
>> ** The real problem is that we have no mechanism for allowing a PL's
>> language/syntax/API to move forward without massive backwards
>> compatibility problems. **
>>
>>
>> We have not, but there are few possibilities:
>>
>> 1. enhance #option command
>> 2. we can introduce PRAGMA command
>> https://en.wikipedia.org/wiki/Ada_(programming_language)#Pragmas
>> <https://en.wikipedia.org/wiki/Ada_%28programming_language%29#Pragmas>
>>
>
> I wanted to break this out separately, because IMO it's the real heart of
> the matter.
>
> I think it would be silly not to allow a global setting of compatibility.
> You certainly don't want to force people to stick magic keywords in their
> code forevermore.
>
> To that end, would GUCs be a workable answer here? That should give you
> the ability to control incompatibilities at a function, user, database and
> global level. It would also allow you to chose between raising a WARNING vs
> a FATAL.
>

GUC are fragile - the source code and settings can be separated.

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.

Using function assigned GUC is similar, but it is looking less robust - and
some editors can forgot this information.

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.

>
> I realize we've had some bad experiences with compatibility GUCs in the
> past, but I'd argue we've also had some good experiences. I see that
> add_missing_from is now completely gone, for example, presumably with no
> complaints. There's probably several other compatibility GUCs we could
> remove now.
>
> --
> 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)
>