integer datetimes

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.

regards, tom lane

On Wed, Feb 14, 2007 at 11:27:31AM -0500, 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.

Certainly, but is it more likely to trip on these in the integer
datetime case, really?

//Magnus

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.

cheers

andrew

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

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. +