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.
Yet
func(column_of_typeX, constant)
ought to be able to resolve correctly when
* no function exists with signature
func(typeX, typeY)
* yet there exists a function
func(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.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
