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 по дате отправления:

Предыдущее
От: Michael Meskes
Дата:
Сообщение: Re: NetBSD/dtime_t
Следующее
От: Christian Robottom Reis
Дата:
Сообщение: Re: CVS repository invalid revision