From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: implement query_start for pg_stat_activity |
Date: | 2003-02-19 06:45:47 |
Message-ID: | 1045637147.582.397.camel@tokyo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
On Wed, 2003-02-19 at 01:04, Tom Lane wrote:
> NAMEDATALEN=32 will have been history for two releases when this gets
> out. I don't agree with artificially constricting a function name to
> conform to an obsolete restriction --- and for *sure* I don't agree with
> renaming an existing function to make it line up with a new, artificial
> name ...
Fair enough.
> > (2) I wasn't sure how to convert a struct timeval into a PostgreSQL
> > timestamp type, so I hacked something together involving ctime() and
> > timestamp_in(), but it seems clearly wrong.
>
> GetCurrentAbsoluteTimeUsec() followed by now() seem to do it at the
> moment ...
Can you elaborate a bit? Since now() returns the time the current txn
started, that doesn't seem to be what I'd need -- and isn't
GetCurrentAbsoluteTimeUsec() essentially just an (ugly) wrapper over
gettimeofday()?
I think a similar function to timeofday() that returns a timestamp would
probably be ideal... (which reminds me, we should probably think about
how to replace timeofday() with something that doesn't return a string).
> Care to offer a proposal for simplifying this code?
To be honest, I wouldn't know where to start -- I don't really know much
about the intricacies of datetime manipulation...
Cheers,
Neil
--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-02-19 07:00:32 | Re: implement query_start for pg_stat_activity |
Previous Message | Tom Lane | 2003-02-19 06:04:51 | Re: implement query_start for pg_stat_activity |