Neil Conway <nconway@klamath.dyndns.org> writes:
> 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.
I think int8_tbl may be used in some of the other tests, so diffs there
are not necessarily a big deal. Did you examine the diffs closely?
> 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)
Yes: it won't work. If reltuples is construed to be 8 bytes by some
compilers and 4 bytes by others, then the struct definition will fail to
overlay onto the storage as seen by the general-purpose tuple access
routines. (We could maybe fix that by having pg_type.h and some other
places conditionally compile the declared size of type int8, but it
ain't worth the trouble.)
> 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...
Sorry, but I have very little patience for arguments that "if it works
on all the machines I use, it's good enough". Especially for a case
like this, where there is zero advantage to using int8 anyway.
Using a float here is not a "workaround", it's the right thing to do.
(The optimizer would only have to convert it to float anyway for its
internal calculations.)
> 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?
So the user-visible column types of pg_class would vary depending on
this implementation detail? Not a good idea IMHO.
regards, tom lane
