Re: Resolving polymorphic functions with related datatypes

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Resolving polymorphic functions with related datatypes
Date: 2008-07-03 10:22:21
Message-ID: 162867790807030322k1ee3e09dn4a9ba3e9cdc8ae2a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Pavel Stehule

> --
> Simon Riggs www.2ndQuadrant.com
> PostgreSQL Training, Services and Support
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-07-03 10:47:48 Re: [WIP] patch - Collation at database level
Previous Message Paul van den Bogaard 2008-07-03 10:01:20 Attaching and using the Postgres shared memory segment