Re: merging some features from plpgsql2 project

2017-01-08 3:27 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> On 1/5/17 11:36 AM, Merlin Moncure wrote:
>
>> The C language really should be considered the gold standard here.
>> Changes did have to be made, like getting rid of the notoriously
>> broken and insecure gets(), but they were made very, very slowly and
>> unobtrusively.
>>
>
> For those not familiar... how did they accomplish that?
>
> I'm certainly fine with changes being made very slowly. We carried the
> missing_From GUC around for like a decade before ditching it. We have other
> GUCs that have defaulted to not allowing silly behavior for a long time as
> well. We might well need to leave the default for compatibility GUCs set to
> current behavior for several more releases, to allow people to start
> specifying which behavior they want.
>
> I agree with Robert that there needs to be consensus that a change needs
> to be made, but frankly I think 50% of this thread was people disagreeing
> with *ANY* change that would be incompatible. IMHO that's a ridiculous
> position that does not match expectations outside of plpgsql. That kind of
> expectation means we have absolutely no way of fixing past mistakes.

> Certainly, there also needs to be agreement on what the new behavior
> should be, but again, what I observed was an adamant insistence that
> absolutely no break would be permitted.

> As for using GUCs for these changes and that impact on extensions, I don't
> see why that won't work for what we're discussing here. In a worst-case
> scenario, extension authors would need to specify what behavior they wanted
> in their extensions instead of blindly accepting the default, by making
> sure those options were set for each function they defined. While it would
> certainly be nice to avoid that extra work, all the necessary
> infrastructure to handle that is already in place. And if we wanted to
> avoid that hassle, we could allow custom GUC settings on extensions, like
> we currently do for roles and databases.

The discussion related to plpgsql2, future development of plpgsql has more
levels, topics

1. incompatible changes - INTO, INTO STRICT, FOUND - there is a agreement
so current behave is not ideal for all cases, but there is not a agreement
so it broken and should be "fixed" - GUC doesn't helps here.

2. new features - the question was "how much we would to move PL/pgSQL from
verbose Ada language to different place - convention against configuration
principle", and what (if) conventions should be default. GUC can partially
helps.

I still hope so there is some space for finding a partial agreement - and
we can do some evolution steps forward.

I would not to use GUC like "We cannot to find a agreement, so we use GUC
and somebody will use this feature, some one not" - it is not way how to do
things better long time.

Jim, Marko, Joel - is there a place, features where we can find a partial
agreement? If it is, then we can move our view there.

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)
>