Re: [PATCH 1/2 v3] [libpq] rework sigpipe-handling macros

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeremy Kerr <jk(at)ozlabs(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: [PATCH 1/2 v3] [libpq] rework sigpipe-handling macros
Date: 2009-07-20 00:42:40
Message-ID: 13485.1248050560@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeremy Kerr <jk(at)ozlabs(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Kerr 2009-07-20 00:47:18 Re: [PATCH v3] Avoid manual shift-and-test logic in AllocSetFreeIndex
Previous Message Alvaro Herrera 2009-07-20 00:37:25 Re: make check failure for 8.4.0