Re: Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing
От | Marko Kreen |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing |
Дата | |
Msg-id | 20120328131316.GA25269@gmail.com обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Wed, Mar 28, 2012 at 08:57:42AM -0400, Robert Haas wrote: > On Wed, Mar 28, 2012 at 8:51 AM, Marko Kreen <markokr@gmail.com> wrote: > >> How about: ".. %10" INT64_FORMAT " .. " ? > > > > Well, it won't work because unlike <inttypes.h>, Postgres *_FORMAT > > includes '%' in it. > > > > I guess that why <inttypes.h> does not do it... > > Hmm, I guess we could change that, but it would create a hazard for > thirty-party code that wants to be cross-version, and for > back-patching. We could work around that by doing something more > complex, like creating additional symbols, but I'm thinking it ain't > worth it just for this. Changing existing definition is bad idea indeed. And long-term path should be to move to standard int types, so another custom definition seems counter-productive. (OTOH, the 2 int64 _FORMATs are the only formats we maintain.) In this case the simple approach would be to use 'long long': ".. %10lld ..", (long long)(..) At least ecpg code uses it freely, and nobody has complained, so I guess we don't have any platforms that do not have it. -- marko
В списке pgsql-hackers по дате отправления: