Re: [HACKERS] Resolving polymorphic functions with related datatypes

2008-07-03 Thread Pavel Stehule
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

2008-07-03 Thread Simon Riggs

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

2008-07-03 Thread Heikki Linnakangas

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

2008-07-03 Thread Simon Riggs

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