From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
Cc: | Gerdan Santos <gerdan(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: \timing interval |
Date: | 2016-09-01 19:01:03 |
Message-ID: | 807.1472756463@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Corey Huinker <corey(dot)huinker(at)gmail(dot)com> writes:
> On Thu, Sep 1, 2016 at 2:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Note that times from 1 second to 1 hour all get the nn:nn.nnn
>> treatment. I experimented with these variants for sub-minute times:
>> ...
>> but it seems like the first variant is not terribly intelligible and
>> the second variant is inconsistent with what happens for longer times.
> Well, if we're looking to be consistent, here's what interval does now:
> ...
> Should we just plug into whatever code that uses?
Well, that code's on the backend side so we're not going to just call it
in any case. And I think we don't want to be quite so verbose as to go up
to hh:mm:ss.fff as soon as we get past 1 second. However, comparing that
output to what I had suggests that maybe it's better to keep a leading
zero in two-digit fields, that is render times like "00:01.234",
"01:23.456", or "01:23:45.678" rather than suppressing the initial zero as
I had in my examples. It's an extra character but I think it reinforces
the meaning.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Corey Huinker | 2016-09-01 19:06:32 | Re: \timing interval |
Previous Message | Corey Huinker | 2016-09-01 18:51:53 | Re: \timing interval |