Re: Resolving polymorphic functions with related datatypes
От | Heikki Linnakangas |
---|---|
Тема | Re: Resolving polymorphic functions with related datatypes |
Дата | |
Msg-id | 486CB3E6.8050204@enterprisedb.com обсуждение исходный текст |
Ответ на | Resolving polymorphic functions with related datatypes (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Resolving polymorphic functions with related
datatypes
|
Список | pgsql-hackers |
Simon Riggs wrote: > I'm using the nvl() function from the orafce package. It is defined as a > polymorphic function so its function signature is > nvl(anyelement, anyelement) > > Now if I try to use the function in this very typical way > nvl(numeric_col, 0) > > we get > > ERROR: function nvl(numeric, integer) does not exist > > The same error occurs if we have nvl(smallint, integer) etc > > This is a real shame 'cos polymorphic functions ought to be a great way > of saving development time and catalog space, yet they seem to fall down > a hole without implicit casting. > > 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). > 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? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: