Andres Freund <and...@2ndquadrant.com> writes: >>> It does *not* combine elog_start and elog_finish into one function if >>> varargs are available although that brings a rather measurable >>> size/performance benefit.
>> Since you've apparently already done the measurement: how much? >> It would be a bit tedious to support two different infrastructures for >> elog(), but if it's a big enough win maybe we should. > Imo its pretty definitely a big enough win. So big I have a hard time > believing it can be true without negative effects somewhere else. Well, actually there's a pretty serious negative effect here, which is that when it's implemented this way it's impossible to save errno for %m before the elog argument list is evaluated. So I think this is a no-go. We've always had the contract that functions in the argument list could stomp on errno without care. If we switch to a do-while macro expansion it'd be possible to do something like do { int save_errno = errno; int elevel = whatever; elog_internal( save_errno, elevel, fmt, __VA__ARGS__ ); } while (0); but this would almost certainly result in more code bloat not less, since call sites would now be responsible for fetching errno. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers