Re: Proposal for updating src/timezone

Поиск
Список
Период
Сортировка
От John Cochran
Тема Re: Proposal for updating src/timezone
Дата
Msg-id CAGQU3n4S=PobYFjiGXE54ae3Aqu6fObcfJCPP=+34XUJQJALRQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal for updating src/timezone  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Proposal for updating src/timezone  (Michael Banck <mbanck@gmx.net>)
Список pgsql-hackers
Agreed. Right now, I'm seeing about updating zic.c to match the IANA code combined with the modifications that postgres did to it. So far, it doesn't look like many functional changes have been done, but due to the use of pgindent, there's a LOT of cosmetic changes that add one heck of a lot of noise in determining the actual differences. After I get the code closely matching the IANA code, I'll submit a patch (unfortunately it will pretty much be an entire replacement of zic.c due to the massive changes IANA did between 2010c and 2014e). I will request very strongly that pgindent not be used again on the IANA code so future maintainers can easily perform a diff between the IANA code and the postgres code to determine the actual differences. I'll then see about doing the same with the other source files in timezone.




On Fri, Jul 18, 2014 at 4:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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



--

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. — C.A.R. Hoare

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Use unique index for longer pathkeys.
Следующее
От: Michael Banck
Дата:
Сообщение: Re: Proposal for updating src/timezone