Re: [PATCH 1/2 v3] [libpq] rework sigpipe-handling macros - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH 1/2 v3] [libpq] rework sigpipe-handling macros
Date
Msg-id 13485.1248050560@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH 1/2 v3] [libpq] rework sigpipe-handling macros  (Jeremy Kerr <jk@ozlabs.org>)
Responses Re: [PATCH 1/2 v3] [libpq] rework sigpipe-handling macros  (Jeremy Kerr <jk@ozlabs.org>)
Re: [PATCH 1/2 v3] [libpq] rework sigpipe-handling macros  (Jeremy Kerr <jk@ozlabs.org>)
List pgsql-hackers
Jeremy Kerr <jk@ozlabs.org> writes:
> However, I'd rather make decisions on data, rather than guessing. Is the 
> actual problem here that some compilers just don't support the 'inline' 
> keyword?

I think Alvaro's complaint is unfounded --- we already have logic
to #define inline as empty if the compiler doesn't support it.
The issue he's thinking of is that non-gcc compilers typically don't
react very well to static function definitions in .h files.  However
that doesn't apply to the proposed usage, since they're not going to
be in a .h file.

However, I think the whole patch is pretty useless.  That code is not
broken as it stands, and doesn't appear to really gain anything from the
proposed change.  Why should we risk any portability questions when the
code isn't going to get either simpler or shorter?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Jeremy Kerr
Date:
Subject: Re: [PATCH 1/2 v3] [libpq] rework sigpipe-handling macros
Next
From: Jeremy Kerr
Date:
Subject: Re: [PATCH v3] Avoid manual shift-and-test logic in AllocSetFreeIndex