Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)
От | Andres Freund |
---|---|
Тема | Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3) |
Дата | |
Msg-id | 744FCAA1-9320-4255-AC08-F8B1DF81D031@anarazel.de обсуждение исходный текст |
Ответ на | Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)
|
Список | pgsql-hackers |
On March 17, 2018 12:25:57 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote: >Andres Freund <andres@anarazel.de> writes: >> I don't think performance is a prime driver here, or shouldn't be at >least. Obviousness / grepability seem much more important. I'd vote >for using my version in master, and yours in the back branches. I can >do that, of you want. > >I dunno, I think the code as I had it is quite obvious. It's just that >I don't really like hard-coding references to INT_MIN/MAX, which I >guess >is a personal style thing rather than anything I can defend well. Certainly harder to grep for. There's lots of other uses of the min/max macros. And the logic to get or right depends onan earlier piece of code ensuring the step is positive... >> I'm OK with skipping the test for now. > >If we're not putting a test into the back branches, then we darn well >better be using the same code there as in HEAD, else we won't know that >it actually solves the problem. I was thinking of committing your version everywhere and then revising in master after a bf cycle. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
В списке pgsql-hackers по дате отправления: