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.
Iacob is maybe little bit too defensive - but why not. The implementation of GUC should not be hard. I see it as best way now. Tomorrow I'll try to find last versions of this patch in mailbox and try to design compatibility mode.
I don't like too much a introduction of new general function raise (proposed by Jim). It is not consistent with current design and it needs a introduction of enums visible from user level. The work with it isn't too much comfortable. If it will be required, then we have it. The original implementation of this proposal was designed in exactly same style.
