From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org,Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Subject: | Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3) |
Date: | 2018-03-17 19:32:33 |
Message-ID: | 744FCAA1-9320-4255-AC08-F8B1DF81D031@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On March 17, 2018 12:25:57 PM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Andres Freund <andres(at)anarazel(dot)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 on an 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-03-17 19:41:15 | Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3) |
Previous Message | Dean Rasheed | 2018-03-17 19:32:12 | Re: MCV lists for highly skewed distributions |