Re: pg_class -> reltuples?

On Thu, 2002-03-07 at 19:54, Tom Lane wrote:
> Neil Conway <nconway(at)klamath(dot)dyndns(dot)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(at)rogers(dot)com>
PGP Key ID: DB3C29FC