Re: Proposal for updating src/timezone

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Proposal for updating src/timezone
Дата
Msg-id 7767.1405715275@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Proposal for updating src/timezone  (John Cochran <j69cochran@gmail.com>)
Ответы Re: Proposal for updating src/timezone  (John Cochran <j69cochran@gmail.com>)
Список pgsql-hackers
John Cochran <j69cochran@gmail.com> writes:
> Did a diff between the 2010c version of localtime.c and the postgres
> version and saw a lot more differences than what could have been expected
> from simple reformatting and adaptation. So I installed gitk and took a
> look at the change history of localtime.c....

> Well, looking at the results, it pretty much put paid to the concept of
> ever importing the IANA code unaltered into the postgres tree. In fact, it
> looks like the original version of localtime.c was based upon one of the
> 2004a thru 2004c versions of the IANA code and since then has been
> independently maintained.

That's certainly true, but I'm not sure that we should give up all that
easily on getting closer to the IANA code again.  For one thing, some of
the thrashing had to do with the fact that we went over to 64-bit
timestamps sooner than the IANA crew did.  I'm assuming that they insist
on 64-bit arithmetic now; we do too, so for instance some of the typedef
hacking might no longer be necessary.

AFAICT from a quick scan of the git logs, the main thing we've done to the
API that's not in IANA is invent pg_next_dst_boundary().  Perhaps that
could be pushed into a separate source file.

Even if we only got to a point where the sources were the same except for
a few narrow patches, it would make tracking their updates much easier.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]