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
