Re: bugfix: --echo-hidden is not supported by \sf statements - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: bugfix: --echo-hidden is not supported by \sf statements |
Date | |
Msg-id | 512D0D2C.50107@dunslane.net Whole thread Raw |
In response to | Re: bugfix: --echo-hidden is not supported by \sf statements (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: bugfix: --echo-hidden is not supported by \sf
statements
|
List | pgsql-hackers |
On 02/26/2013 02:12 PM, Tom Lane wrote: > Stephen Frost <sfrost@snowman.net> writes: >> * Pavel Stehule (pavel.stehule@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. > > If we're going to mess with this area can I put in a plea to get \ef and \sf to handle full parameter specs? I want to be able to c&p from the \df output to see the function. But here's what happens: andrew=# \df json_get List of functions Schema | Name | Resultdata type | Argument data types | Type ------------+----------+------------------+-----------------------------------------------+-------- pg_catalog | json_get| json | from_json json, element integer | normal pg_catalog | json_get | json | from_json json, VARIADIC path_elements text[] | normal (2 rows) andrew=# \sf json_get (from_json json, element integer ) ERROR: invalid type name "from_json json" cheers andrew
pgsql-hackers by date: