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 I expect the various numeric/integer types we have to play
> > nicely together without tears.
>
> So, it would be analogous to the 'unknown' type, but for numeric
> literals instead of text literals. Seems reasonable. It still wouldn't
> allow nvl(1::bigint, 2::int4), though, just as the unknown type doesn't
> help with nvl('foo'::text, 'bar'::varchar).
Well, it would be nice if we could work with the unknown type also, but
I don't expect that's meaningful.
Yetfunc(column_of_typeX, constant)
ought to be able to resolve correctly when
* no function exists with signaturefunc(typeX, typeY)
* yet there exists a functionfunc(anyelement, anyelement)
* and an implicit cast exists typeY => typeX
(assuming constant is normally resolved to typeY)
> > If we can do it for indexes, can we do it for polymorphic functions also
> > when there is no matching function?
>
> Umm, what do indexes have to do with this?
Nothing, except that we solved implicit casting for that situation, so
perhaps it is possible for this situation...
Anyway, just posting for reference. Workarounds exist, just wanted to
make sure the issue was mentioned.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support