Gregory Stark <[EMAIL PROTECTED]> writes: > I think what you're suggesting is making integer and floating point constants > like 0 and 0.1 be treated as "unknown" or perhaps a different kind of unknown, > "unknown integral type" and "unknown numeric type".
No, that would be a pretty dangerous way to go about it, because it would have side-effects on all sorts of queries whether or not they made any use of polymorphic functions. Plus, it would only fix the issue for numeric-group types, but the same thing would come up if you had, say, NVL(text, varchar). What I'd be inclined to think about is making check_generic_type_consistency and related functions allow the arguments matched to ANYELEMENT to be of different actual types so long as select_common_type could determine a unique type to coerce them all to. It'd take some refactoring (notably, because select_common_type wants to throw error on failure, and because there'd have to be a way to pass back the type that was selected for use later). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers