Обсуждение: Question about FUNCDETAIL_MULTIPLE

I was wondering what the philosophy is behind letting an "ambiguous" 
function be created in the first place. Is this for backwards 
compatibility or perhaps for historical reasons? Could someone clarify 
this please?


Consider the following example:

(
FYI:
parse_func.c->ParseFuncOrColumn->164
parse_func.c->ParseFuncOrColumn->810
parse_func.c->ParseFuncOrColumn->836
namespace.c->FuncnameGetCandidates->607
namespace.c->FuncnameGetCandidates->826
parse_func.c->ParseFuncOrColumn->224
)


-----------------------------------------------------------------------------
create or replace function foo1(int,int default 1,int default 2) returns 
int as
$$    select $1+$2+$3
$$
language sql;


create or replace function foo1(int,int default 1) returns int as
$$    select $1+$2
$$
language sql;


select * from foo1(10,10)

ERROR:  function foo1(integer, integer) is not unique
LINE 15: select * from foo1(10,10)                       ^
HINT:  Could not choose a best candidate function. You might need to add 
explicit type casts.
-----------------------------------------------------------------------------

-- 
Regards,
Gevik

2009/6/4 Gevik Babakhani <pgdev@xs4all.nl>:
> I was wondering what the philosophy is behind letting an "ambiguous"
> function be created in the first place. Is this for backwards compatibility
> or perhaps for historical reasons? Could someone clarify this please?
>

This is +/- for historical reasons. We used original algorithm for
ambiguous function identification.

regards
Pavel Stehule

>
> Consider the following example:
>
> (
> FYI:
> parse_func.c->ParseFuncOrColumn->164
> parse_func.c->ParseFuncOrColumn->810
> parse_func.c->ParseFuncOrColumn->836
> namespace.c->FuncnameGetCandidates->607
> namespace.c->FuncnameGetCandidates->826
> parse_func.c->ParseFuncOrColumn->224
> )
>
>
>
> -----------------------------------------------------------------------------
> create or replace function foo1(int,int default 1,int default 2) returns int
> as
> $$
>    select $1+$2+$3
> $$
> language sql;
>
>
> create or replace function foo1(int,int default 1) returns int as
> $$
>    select $1+$2
> $$
> language sql;
>
>
> select * from foo1(10,10)
>
> ERROR:  function foo1(integer, integer) is not unique
> LINE 15: select * from foo1(10,10)
>                       ^
> HINT:  Could not choose a best candidate function. You might need to add
> explicit type casts.
> -----------------------------------------------------------------------------
>
> --
> Regards,
> Gevik
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Gevik Babakhani <pgdev@xs4all.nl> writes:
> I was wondering what the philosophy is behind letting an "ambiguous" 
> function be created in the first place. Is this for backwards 
> compatibility or perhaps for historical reasons?

Neither; it's a feature, and one we quite like.  For example, would you
really prefer that the six different versions of abs() had to have
different names?

regression=# \df abs                         List of functions  Schema   | Name | Result data type | Argument data
types|  Type  
 
------------+------+------------------+---------------------+--------pg_catalog | abs  | bigint           | bigint
       | normalpg_catalog | abs  | double precision | double precision    | normalpg_catalog | abs  | integer
|integer             | normalpg_catalog | abs  | numeric          | numeric             | normalpg_catalog | abs  |
real            | real                | normalpg_catalog | abs  | smallint         | smallint            | normal
 
(6 rows)

Even if you were willing to do that, what about the forty-seven
distinct versions of "+"?  Overloaded operators are not fundamentally
different from overloaded functions.
        regards, tom lane

Tom Lane wrote:
> Gevik Babakhani <pgdev@xs4all.nl> writes:
>> I was wondering what the philosophy is behind letting an "ambiguous" 
>> function be created in the first place. Is this for backwards 
>> compatibility or perhaps for historical reasons?
> 
> Neither; it's a feature, and one we quite like.  For example, would you
> really prefer that the six different versions of abs() had to have
> different names?
> 
> regression=# \df abs
>                           List of functions
>    Schema   | Name | Result data type | Argument data types |  Type  
> ------------+------+------------------+---------------------+--------
>  pg_catalog | abs  | bigint           | bigint              | normal
>  pg_catalog | abs  | double precision | double precision    | normal
>  pg_catalog | abs  | integer          | integer             | normal
>  pg_catalog | abs  | numeric          | numeric             | normal
>  pg_catalog | abs  | real             | real                | normal
>  pg_catalog | abs  | smallint         | smallint            | normal
> (6 rows)
> 
> Even if you were willing to do that, what about the forty-seven
> distinct versions of "+"?  Overloaded operators are not fundamentally
> different from overloaded functions.
> 
>             regards, tom lane

I understand the value of this future. This basically means that one has 
to keep the function naming and argument types as simple as logically 
possible in order to avoid situations like I described in my previous 
example.

(Sorry for bothering you with questions likes this. I am trying to 
understand PG)


-- 
Regards,
Gevik