Re: proposal: PL/Pythonu - function ereport
От | Jim Nasby |
---|---|
Тема | Re: proposal: PL/Pythonu - function ereport |
Дата | |
Msg-id | 56B16115.7050602@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: proposal: PL/Pythonu - function ereport (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: proposal: PL/Pythonu - function ereport
|
Список | pgsql-hackers |
On 2/2/16 4:52 PM, Alvaro Herrera wrote: > Robert Haas wrote: > >> The eventual committer is likely to be much happier with this patch if >> you guys have achieved consensus among yourselves on the best >> approach. >> >> (Disclaimer: The eventual committer won't be me. I'm not a Python >> guy. But we try to proceed by consensus rather than committer-dictat >> around here, when we can. Obviously the committer has the final say >> at some level, but it's better if that power doesn't need to be >> exercised too often.) > > Actually I imagine that if there's no agreement between author and first > reviewer, there might not *be* a committer in the first place. Perhaps > try to get someone else to think about it and make a decision. It is > possible that some other committer is able to decide by themselves but I > wouldn't count on it. +1. FWIW, I'd think it's better to not break backwards compatibility, but I'm also far from a python expert. It might well be worth adding a plpython GUC to control the behavior so that there's a migration path forward, or maybe do something like the 'import __future__' that python is doing to ease migration to python 3. -- 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
В списке pgsql-hackers по дате отправления: