Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
