Re: [HACKERS] merging some features from plpgsql2 project

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: [HACKERS] merging some features from plpgsql2 project
Дата
Msg-id 895db5bd-65d6-c6b2-7149-8a7f8d9eeb49@BlueTreble.com
обсуждение исходный текст
Ответ на Re: [HACKERS] merging some features from plpgsql2 project  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: [HACKERS] merging some features from plpgsql2 project  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
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)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] merging some features from plpgsql2 project