Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)

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.

In response to

Responses

Browse pgsql-hackers by date

  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