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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
