From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Replacing time_t fields in pg_control and elsewhere |
Date: | 2008-02-17 19:05:25 |
Message-ID: | 47B88575.9070805@sun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane napsal(a):
<snip>
> pg_time_t: only one-second resolution. Also, since this is typedef'd
> as int64, the field-width problem comes right back to haunt us on
> machines where INT64_IS_BROKEN. On the other hand, it's not clear
> that there are any such machines anymore, and furthermore such a machine
> is going to have a different idea of the width of some other pg_control
> fields such as system_identifier anyway.
I think one-second resolution is OK. I don't expect that currently there
is some machine with INT64_IS_BROKEN. We can add some extra check to
configure if we want to be sure.
<snip>
> There are various modules that use time_t internally to store current
> or recent values of time(NULL), and it's probably all right to leave
> those as-is as long as the value is not exposed outside the module.
> But maybe we should convert them to pg_time_t too, just to have a
> uniform coding rule "don't use time_t". Thoughts?
It is good rule. We should add pg_time() function as a
replacement/wrapper of time() function.
Zdenek
From | Date | Subject | |
---|---|---|---|
Next Message | Christian Robottom Reis | 2008-02-17 22:51:01 | Re: CVS repository invalid revision |
Previous Message | Michael Meskes | 2008-02-17 18:45:40 | Re: NetBSD/dtime_t |