Re: integer datetimes - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: integer datetimes |
Date | |
Msg-id | 200702170127.l1H1R3F04449@momjian.us Whole thread Raw |
In response to | Re: integer datetimes (Magnus Hagander <magnus@hagander.net>) |
List | pgsql-hackers |
OK, mention removed. We can always re-add it if we find we need to warn people away from integer timestamps again. --------------------------------------------------------------------------- Magnus Hagander wrote: > 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/installation.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v retrieving revision 1.282 diff -c -c -r1.282 installation.sgml *** doc/src/sgml/installation.sgml 3 Feb 2007 23:01:06 -0000 1.282 --- doc/src/sgml/installation.sgml 17 Feb 2007 01:24:57 -0000 *************** *** 965,973 **** the full range (see <![%standalone-include[the documentation about datetime datatypes]]> <![%standalone-ignore[<xref linkend="datatype-datetime">]]> ! for more information). 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. </para> </listitem> </varlistentry> --- 965,971 ---- the full range (see <![%standalone-include[the documentation about datetime datatypes]]> <![%standalone-ignore[<xref linkend="datatype-datetime">]]> ! for more information). </para> </listitem> </varlistentry>
pgsql-hackers by date: