Stephen Frost <sfr...@snowman.net> writes:
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> Minimally \ef needs exact specification - you cannot to edit more
>> functions in same time. So we have to be able identify if there are no
>> selected function or if there are more functions. We can write a
>> auxiliary function that returns list of function oids for specified
>> signature - but it is relative much more code and it is hard to
>> implement for older versions - but we can use regproc and regprocedure
>> there.
> Using regproc and regprocedure is the wrong approach here and will be a
> pain to maintain as well as a backwards incompatible change to how they
> behave. We have solved this problem already and what \df does is exactly
> the right answer.
Well, actually I think Pavel's got a point. What about overloaded
functions? In \df we don't try to solve that problem, we just print
them all:
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)
In \ef you need to select just one of these functions, but \df doesn't
have any ability to do that:
regression=# \df abs(int)
List of functions
Schema | Name | Result data type | Argument data types | Type
--------+------+------------------+---------------------+------
(0 rows)
Now, maybe we *should* teach \df about handling parameter types and
then \ef can piggyback on it, but that code isn't there now.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
