Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Date
Msg-id 22234.1582147930@sss.pgh.pa.us
Whole thread Raw
In response to Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes:
> On Wed, Feb 19, 2020 at 12:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Boy, I'd be pretty darn hesitant to go there, even with our new
>> expectation of C99 compilers.  What we found out when we last experimented
>> with non-static inlines was that the semantics were not very portable nor
>> desirable.  I've forgotten the details unfortunately.

> My original approach to inlining was to alter the nbtsearch.c
> _bt_compare() callers (the majority) to call _bt_compare_inl(). This
> function matches our current _bt_compare() function, except it's a
> static inline. A "new" function, _bt_compare(), is also added. That's a
> shim function that simply calls _bt_compare_inl().

Yeah, that's pretty much the approach we concluded was necessary
for portable results.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Next
From: Alex Malek
Date:
Subject: bad wal on replica / incorrect resource manager data checksum inrecord / zfs