Re: Bug#342369: PostgreSQL 8.1.0 RHEL / Debian incompatible

* Stephan Szabo (sszabo@megazone.bigpanda.com) wrote:
> On Tue, 13 Dec 2005, Anand Kumria wrote:
> > On Mon, Dec 12, 2005 at 09:41:47AM +0100, Richard van den Berg wrote:
> > > Tom Lane wrote:
> > > > You've got that 100% backwards: you should be complaining to Debian that
> > > > it's not their business to editorialize on the default setting.
[...]
> > If Tom could present an actual reason why it shouldn't be enabled, I'm sure
> > Martin (Pitt) would be interested. But Stephen Frost and Peter
> > Eisentraut as well as others seem to be suggesting that Debian default is
> > sane.

I think what Peter said is probably correct- it defaults to double
because some compilers don't support 64bit integers, or it'd be lots
slower because the architecture doesn't support it and so there's alot
of overhead.

> In and of itself it's a good option.  However, choosing that option means
> that Debian is saying that compatibility of data files with default
> compiled PostgreSQL is not one of its primary concerns, which is a
> reasonable statement, but it's still not the community's problem when
> people can't move data to it.

Honestly, in the end I think the default should be changed.  It could
fall-back to double with a warning (if it doesn't already) if the
compiler doesn't support 64bit integers.  It sure seems like the general
feeling is that, given the choice, 64bit integer timestamps are
preferred.  As the situations where you wouldn't want to use 64bit
integer timestamps are alot, lot smaller than the cases where you would
it's more sensible to have the default be to use them if possible.

Of course, another thought would be to have the rpms default to having
it enabled since the rpms provided on postgresql.org are for
architectures which should deal quite happily with 64bit integers (i686
and x86_64, though I don't actually see any rpms for x86_64, just the
directories, kind of odd).  I'm reasonably confident that most rpm-based
architectures supported today support 64bit integers quite well, in
fact...

This really *should* be backwards, funny enough; Debian with support for
things like m68k (which doesn't have hardware 64bit integer support,
afaik) could be argued to use the default while rpm-based distros could
probably move to 64bit integer timestamps without any concerns over
using inefficient datatypes for the architectures those rpms would
likely be used on.

I don't think the Debian default should be changed though.  If, say, an
m68k user actually complained about the default not being the right
option for them then I'd say we should consider having configure options
be different for those architectures and not that we should move
everyone to using doubles.

    Thanks,

        Stephen