I said:
> You can work around the issue by explicitly coercing the literal to
> numeric, or by single-quoting it (so that its type is not determined
> until after agency_uid is known to be numeric), or by updating to PG
> 7.2 which uses a slightly different set of type-resolution rules.
Actually, you'll probably still need to do coercion in 7.2. I was
fooled by a poorly chosen test case:
test72=# select * from z where n1 = 12345678901234567890;
n1 | f1
----+----
(0 rows)
But:
test72=# select * from z where n1 = 1234567890123;
ERROR: Unable to identify an operator '=' for types 'numeric' and 'double precision'
You will have to retype this query using an explicit cast
What's happening here is that 7.2 defaults a number literal to be type
numeric if it has too many significant digits to be stored accurately
as a float. But for values in between int and numeric, the default
interpretation is still float, and we still don't make the choice
between exact and inexact comparison for you.
regards, tom lane