From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martin Weinberg <weinberg(at)osprey(dot)astro(dot)umass(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Why "ERROR: dtoi4: integer out of range" on pg_dump |
Date: | 2001-09-03 21:46:29 |
Message-ID: | 6676.999553589@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martin Weinberg <weinberg(at)osprey(dot)astro(dot)umass(dot)edu> writes:
> DumpComment: SELECT failed: 'ERROR: dtoi4: integer out of range
Hmm. I can reproduce this error message if I suppose that you have
OIDs exceeding 2 billion. pg_dump will produce queries like:
regression=# select * from pg_description where objoid = 2500000000;
ERROR: dtoi4: integer out of range
A short-term workaround is to hack pg_dump so that it explicitly coerces
the literal to OID and/or quotes the literal:
regression=# select * from pg_description where objoid = 2500000000::oid;
objoid | classoid | objsubid | description
--------+----------+----------+-------------
(0 rows)
regression=# select * from pg_description where objoid = '2500000000';
objoid | classoid | objsubid | description
--------+----------+----------+-------------
(0 rows)
This is done in many places in pg_dump, but not in DumpComment which is
relatively new code :-(
A longer-term question is how to persuade the parser to get this right
without such help. I think that this is another variant of the
perennial numeric-precision issue and will not be real easy to fix.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Elphick | 2001-09-03 22:11:54 | Re: Conditional operators ALL, ANY in WHERE clause |
Previous Message | Bruce Momjian | 2001-09-03 21:19:44 | Re: Re: Escaping strings for inclusion into SQL queries |