Re: pg_class -> reltuples?
От | Neil Conway |
---|---|
Тема | Re: pg_class -> reltuples? |
Дата | |
Msg-id | 1015557743.19014.138.camel@jiro обсуждение исходный текст |
Ответ на | Re: pg_class -> reltuples? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_class -> reltuples?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: