Re: merging some features from plpgsql2 project

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