> I think there is some confusion here. The runtime checks Andreas was > talking about was allowing a double of 64.0 to cast to an int4 while > disallowing 64.1 from being cast to an int4 because it is not a hole > number.
Yes, and Tom's proposal for numbers is sufficient for constants, since the 64.0 will initially be an int2 and thus do the correct thing together with an int4, and the 64.1 constant will be a numeric, and thus also do the correct thing with all other types. It is not sufficient for the optimizer for joins though, since it cannot use the int4 index when confronted with "where tab1.int4col = tab2.numericcol". Here only a runtime (non aborting) check would help. Maybe this could be overcome if the index access (or something inbetween) would allow a "numeric" constant for an int4 index (If the "numeric" value does not cleanly convert to int4, return no rows). Andreas ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
