Re: Question about FUNCDETAIL_MULTIPLE

From: Gevik Babakhani <pgdev(at)xs4all(dot)nl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Question about FUNCDETAIL_MULTIPLE
Date: 2009-06-04 14:44:59
Message-ID: 4A27DDEB.9080605@xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Gevik Babakhani <pgdev(at)xs4all(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Aidan Van Dyk 2009-06-04 14:45:38 Re: Improving the ngettext() patch
Previous Message Tom Lane 2009-06-04 14:21:28 Re: Improving the ngettext() patch