Re: proposal: PL/Pythonu - function ereport

On Tue, Feb 2, 2016 at 10:39 AM, Catalin Iacob <iacobcatalin(at)gmail(dot)com> wrote:
> On Tue, Feb 2, 2016 at 3:48 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> If we decided to break compatibility, then we have to do explicitly. Thid
>> discussion can continue with commiter, but send path with duplicitly defined
>> functions has not sense for me. Currently I out of office, so I cannot to
>> clean it. 4.2 I should to work usually
>
> I think I didn't make myself clear so I'll try again.
>
> There are 2 options:
>
> 1. keep info etc. unchanged and add raise_info etc.
> 2. change behaviour of info etc. and of course don't add raise_*
>
> You already implemented 1. I said I think 2. is better and worth the
> compatibility break in my opinion. But the committer decides not me.
>
> Since 1. is already done, what I propose is: let's finish the other
> aspects of the patch (incorporate my docs updates and details in Error
> instead of SPIError) then I'll mark this ready for committer and
> summarize the discussion. I will say there that option 1. was
> implemented since it's backward compatible but that if the committer
> thinks option 2. is better we can change the patch to implement option
> 2. If you do the work for 2 now, the committer might still say "I want
> 1" and then you need to do more work again to go back to 1. Easier to
> just stay with 1 for now until we have committer input.

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

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company