Re: integer datetimes
От | Magnus Hagander |
---|---|
Тема | Re: integer datetimes |
Дата | |
Msg-id | 20070214204200.GA27656@svr2.hagander.net обсуждение исходный текст |
Ответ на | Re: integer datetimes (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: integer datetimes
|
Список | pgsql-hackers |
On Wed, Feb 14, 2007 at 12:38:12PM -0500, Andrew Dunstan wrote: > Tom Lane wrote: > >Magnus Hagander <magnus@hagander.net> writes: > > > >>Our docs for the integer datetime option says: > >>Note also that the integer datetimes > >>code is newer than the floating-point code, and we still find bugs in it > >>from time to time. > >> > > > > > >>Is the last sentence about bugs really true anymore? At least the > >>buildfarm > >>seems to have a lot *more* machines with it enabled than without. > >> > > > >Buildfarm proves only that the regression tests don't expose any bugs, > >not that there aren't any. > > > > > >>(I'm thinking about making it the defautl for the vc++ build, which is > >>why I came across that) > >> > > > >FWIW, there are several Linux distros that build their RPMs that way, > >so it's not like people aren't using it. But it seems like we find bugs > >in the datetime/interval stuff all the time, as people trip over > >different weird edge cases. > > > > > > > > I think it's disappointing, to say the least, that we treat this code as > a sort of second class citizen. BTW, the buildfarm has a majority of > machines using it by design - it's in the default set of options in the > distributed config file. If we think there are bugs we haven't found, > then we need to engage in some sort of analytical effort to isolate > them. I don't see any reason in principle why this code should be any > more buggy than the float based datetimes, and I see plenty of reason in > principle why we should make sure it's right. That was exactly what I thought, which is why I was kinda surprised to see that note in the configure stuff. If we go with that, then we can say that *any* new feature is less tested, no? ;-) //Magnus
В списке pgsql-hackers по дате отправления: