Daniel Kalchev [EMAIL PROTECTED] writes:
There is more to it:
customer=# select max(oid) from croute;
max
-
-2144025472
(1 row)
How to handle this?
Use a more recent Postgres release. max(oid) behaves as expected in
7.2. Before that it was piggybacking on
Has anyone seen this:
ERROR: dtoi4: integer out of range
on 7.1.3
What worries me, is that at startup time, the log shows:
DEBUG: database system was shut down at 2002-04-02 23:16:52 EEST
DEBUG: CheckPoint record at (82, 1928435208)
DEBUG: Redo record at (82, 1928435208); Undo record at
An followup to my previous post.
It turned out to be an query containing oid = somenumber called from perl script. Is
it possible that the default type conversion functions do not work as expected?
Changing this to oid = oid(somenumber) worked as expected.
Daniel
Daniel Kalchev [EMAIL PROTECTED] writes:
It turned out to be an query containing oid = somenumber called from perl script.
Is it possible that the default type conversion functions do not work as expected?
No, but you do have to cast an oversize value to oid explicitly to
prevent it from being
Tom Lane said:
This is one of a whole raft of cases involving undesirable assignment
of types to numeric constants; see past complaints about int4 being used
where int2 or int8 was wanted, numeric vs float8 constants, etc etc.
We're still looking for a promotion rule that does what you
Daniel Kalchev [EMAIL PROTECTED] writes:
So in essence this means that my best bet is to again dump/reload the
database...
Either that or fix your queries to cast the literals explicitly.
regards, tom lane
---(end of
Tom Lane said:
Daniel Kalchev [EMAIL PROTECTED] writes:
So in essence this means that my best bet is to again dump/reload the
database...
Either that or fix your queries to cast the literals explicitly.
There is more to it:
customer=# select max(oid) from croute;
max
