Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)
Date
Msg-id 744FCAA1-9320-4255-AC08-F8B1DF81D031@anarazel.de
Whole thread Raw
In response to Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: MCV lists for highly skewed distributions
Next
From: Tom Lane
Date:
Subject: Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)