On 9/28/14, 7:49 AM, Bogdan Pilch wrote:
> I have created a small patch to postgres source (in particular the
> psql part of it) that modifies the way time spent executing the SQL
> commands is printed out.
>
> The idea is to have a human readable time printed
There are already a wide range of human readable time interval output
formats available in the database; see the list at
http://www.postgresql.org/docs/current/static/datatype-datetime.html#INTERVAL-STYLE-OUTPUT-TABLE
If none of those are acceptable to you, it would be difficult but not
impossible to justify something new. I could see tweaking one of those
into a slightly updated new style aimed at this specific job, especially
since it doesn't have to consider things like negative intervals.
There's value in printing time measurements using one of these interval
styles sometimes, instead of the relatively raw values given right now.
It would need to be an option though, and one that let the user allow
choosing any of the supported interval formats. I personally would
prefer to never see the existing format the number is reported in go
away--too much software already expects it to be there, in that format.
But adding this human readable version after that, when the user asks
specifically for it, could be an acceptable addition.
So there's a rough spec for the job you'd have to take on here. I'd
expect it to expand in scope almost immediately to also consider the
output of similar time intervals from mechanisms like
log_min_duration_statement, too though, rather than just focusing on
psql timing data. There's a whole second round of almost inevitable
scope creep to working on this.
If you were hoping what you submitted might be considered directly,
sorry; that's not going to happen. Handling input and output of times
and dates is a very deep topic, and small patches trying to adjust such
behavior without grappling with the full complexity are normally
rejected outright. There are cases where the existing code just has
simple hacks in there now that could easily be whacked around. But once
the topic of cleaning those up appears, swapping to an alternate simple
hack is rarely how that goes. It normally heads toward considering the
full right thing to do to handle all cases usefully.
--
Greg Smith greg.smith@crunchydatasolutions.com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/