Hi everybody,
The bigint problem was probably a typo because I had to type the entire definitions, as the server is on a vpn and I don't had access with my machine where I wrote the mail, and the 7.4.2 was surely a typo... ;) I apology...
OK so beginning on Monday I will test the config on a 8.2.x to verify the performance issues, but I also found some disturbing info's on the net, that the index may be corrupted because of the big difference between an index entry which is deleted and the new value inserted afterwards, which should not be an issue with a btree, but do you guys know something more about it, sorry I'm really good in SQL but in Postgre I'm still a beginner.
What the version belongs, so I know that it's not the actual bug fix, but as it is used in a running prod system and as my employer began considering the migration a year ago and so they froze the version waiting for an major update.
Thanks really to everybody here who already helped me a lot... Thanks!!!
Sven Clement
2007/8/4, Tom Lane <tgl@sss.pgh.pa.us>:Andrew Kroeger <andrew@sprocks.gotdns.com> writes:
> With the table definitions you posted, one of the first things I noticed
> was that the default value for an integer column was a bigint value. I
> did some quick 32-bit math and found that the smallest legal 32-bit
> integer value is -2147483648, not -2147483684 (notice the last 2 numbers
> are transposed).
Oooh, good catch, but 7.4 seems to notice the overflow all right:
regression=# create temp table foo(f1 int default -2147483684::bigint);
CREATE TABLE
regression=# insert into foo default values;
ERROR: integer out of range
regression=# select version();
version
----------------------------------------------------------------
PostgreSQL 7.4.17 on hppa-hp-hpux10.20, compiled by GCC 2.95.3
(1 row)
So I think we can conclude that the OP never actually uses this default.
regards, tom lane
--
DSIGN.LUSven Clement
+352 621 63 21 18
sven@dsign.luwww.dsign.lu
