Horton

Re: Re: [COMMITTERS] pgsql: pg_test_timing utility, to measure clock monotonicity and timing

Marko Kreen <markokr@gmail.com>

View thread
From: Marko Kreen <markokr@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-03-28T13:13:16Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_test_timing utility, to measure clock monotonicity and timing cost.

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