Re: proposal: PL/Pythonu - function ereport

Hi

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

Regards

Pavel