On Tue, Feb 2, 2016 at 3:48 PM, Pavel Stehule <pavel.steh...@gmail.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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers