On Wed, Sep 28, 2016 at 12:02 PM, Emre Hasegeli <e...@hasegeli.com> wrote:
>> `make check` finds differences per the attached. Please >> investigate why the regression tests are failing and what the >> appropriate response is. > > I fixed the first one and workaround the second with COLLATE "C". I > have how my changes caused this regression. > > "select_views" test runs "SELECT name, #thepath FROM iexit ORDER BY 1, > 2" and expects to get rows in this order: > >> I- 580 Ramp | 8 >> I- 580/I-680 Ramp | 2 > > With the collation on my laptop, this is actually true: > >> regression=# select 'I- 580/I-680 Ramp' < 'I- 580 >> Ramp'; >> ?column? >> ---------- >> t >> (1 row) > > However, on the Linux server, I am testing it is not: > >> regression=# select 'I- 580 Ramp' < 'I- 580/I-680 >> Ramp'; >> ?column? >> ---------- >> f >> (1 row) > > Do you know how it is not failing on the master? Well, those two results are not contradictory -- notice that you switched the order of the values in the comparison. I don't think you've really found the explanation yet. >> [discussing inline static functions compared to macros for min()/max(), etc.] >> I suspect that they will be as fast or faster, and they eliminate >> the hazard of multiple evaluation, where a programmer might not be >> aware of the multiple evaluation or of some side-effect of an >> argument. > > I reworked the the patches to use inline functions and fixed the > problems I found. The new versions are attached. Will take a look and post again. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
