On Thu, 2002-03-07 at 19:54, Tom Lane wrote:
> Neil Conway <nconway@klamath.dyndns.org> writes:
> > I have no problem making restrictions on data types for portability, but
> > at least we should be consistent:
>
> We *are* consistent. int8 is not used in the system catalogs, and where
> it is used, the system will continue to function if it's implemented as
> a 32-bit datatype. (At least, things still worked the last time I tried
> turning off HAVE_LONG_LONG_INT. If someone broke it since then, it
> needs to be fixed.)
9 regression tests fail without HAVE_LONG_LONG_INT on a 32-bit machine
(int8, constraints, select_implicit, select_having, subselect, union,
aggregates, misc, rules). It's pretty obvious that int8 should fail, but
the others look like bugs.
As for the original question, maybe I'm missing something obvious, but
is there a reason why reltuples can't be an int8? (which is already
typedef'ed to a int4 on broken machines/compilers) This would mean that
on machines without a 64-bit int type, tables greater than 2^32 rows
can't be stored (or at least, reltuples breaks). But I'm inclined to
dismiss those platforms as broken, anyway...
In any case, I think the current situation is the wrong way around:
we're using a workaround on _all_ platforms, just to avoid breaking a
few old systems. Wouldn't it make more sense to use an int8 by default,
and fall back to a floating-point workaround if the default, optimal
solution isn't available?
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC