Re: pgsql-server/src/timezone pgtz.h
От | Bruce Momjian |
---|---|
Тема | Re: pgsql-server/src/timezone pgtz.h |
Дата | |
Msg-id | 200405010208.i4128sl08563@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql-server/src/timezone pgtz.h (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-committers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I thought about that but I figured the less we change the tz library, > > the easier it will be to replace later. > > I have come to the conclusion that trying to minimize changes to the tz > library is a bad tradeoff. It's not going to be a minimally sized diff > for long. For instance, do you propose to exclude the tz code from all > future pgindent runs? If you look at the changes we made in the regex > library to make it minimally compliant with our own coding standards, > they were pretty extensive. The same is probably going to happen to the > tz code. For one thing, it is definitely not going to have K&R-style > function declarations for long --- those are trouble waiting to happen. > > For another thing, it's not going to try to emulate the C library's API > for long, because getting out from under that brain-dead API is exactly > the reason for wanting to have our own timezone code. (I suspect the > only part of this code we really want in the long run is zic.c.) > > In any case we should certainly not fix portability failures in the tz > code by breaking our other code, or even just risking breaking it. I wasn't aware we were going to be gutting it. I am still trying to just get it to work on Unix. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-committers по дате отправления: