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
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 |