Re: Replacing time_t fields in pg_control and elsewhere
От | Zdenek Kotala |
---|---|
Тема | Re: Replacing time_t fields in pg_control and elsewhere |
Дата | |
Msg-id | 47B88575.9070805@sun.com обсуждение исходный текст |
Ответ на | Replacing time_t fields in pg_control and elsewhere (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: