Re: Resolving polymorphic functions with related datatypes - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Resolving polymorphic functions with related datatypes
Date
Msg-id 486CB3E6.8050204@enterprisedb.com
Whole thread Raw
In response to Resolving polymorphic functions with related datatypes  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Resolving polymorphic functions with related datatypes  (Simon Riggs <simon@2ndquadrant.com>)
List 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 by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: [WIP] patch - Collation at database level
Next
From: "Heikki Linnakangas"
Date:
Subject: Re: Attaching and using the Postgres shared memory segment