Re: [HACKERS] Resolving polymorphic functions with related datatypes
2008/7/3 Simon Riggs [EMAIL PROTECTED]: 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Resolving polymorphic functions with related datatypes
On Thu, 2008-07-03 at 12:22 +0200, Pavel Stehule wrote: 2008/7/3 Simon Riggs [EMAIL PROTECTED]: 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Resolving polymorphic functions with related datatypes
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Resolving polymorphic functions with related datatypes
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
