>
> 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 (no
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
On Thu, 2008-07-03 at 13:54 +0100, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > On Thu, 2008-07-03 at 14:11 +0300, Heikki Linnakangas wrote:
> >
> >> > What I'd like it to do is to recognise that the 0 should be cast
> >> > implicitly to another datatype within the same
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Thu, 2008-07-03 at 14:11 +0300, Heikki Linnakangas wrote:
>
>> > What I'd like it to do is to recognise that the 0 should be cast
>> > implicitly to another datatype within the same family. I want and expect
>> > nvl(char_column, 0)
>> > to fail, but
