From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Resolving polymorphic functions with related datatypes |
Date: | 2008-07-03 10:51:38 |
Message-ID: | 1215082298.3845.769.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2008-07-03 at 12:22 +0200, Pavel Stehule wrote:
> 2008/7/3 Simon Riggs <simon(at)2ndquadrant(dot)com>:
> > 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.
> >
> > If we can do it for indexes, can we do it for polymorphic functions also
> > when there is no matching function?
> >
>
> +1
>
> there is similar problem with literal constant.
as well as NULL itself, which doesn't have a type when attempting to
resolve to anyelement.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-07-03 11:11:34 | Re: Resolving polymorphic functions with related datatypes |
Previous Message | Zdenek Kotala | 2008-07-03 10:47:48 | Re: [WIP] patch - Collation at database level |