Re: FWD: Re: Updated backslash consistency patch - Mailing list pgsql-hackers

From Joshua D. Drake
Subject Re: FWD: Re: Updated backslash consistency patch
Date
Msg-id 1232059878.12600.283.camel@jd-laptop.pragmaticzealot.org
Whole thread Raw
In response to Re: FWD: Re: Updated backslash consistency patch  (Josh Berkus <josh@agliodbs.com>)
Responses Re: FWD: Re: Updated backslash consistency patch  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Thu, 2009-01-15 at 14:32 -0800, Josh Berkus wrote:
> Tom,
> 

> Personally, I don't care that much about what Hungarian Notation we use, 
> as long as we try to make it consistent with \dt, \dv, \dn etc.  My main 
> objection to requiring \dfU to get only user functions is that it's not 
> what we do with \dt.

O.k. since Tom rightfully complained that everyone was bleating about
this patch without actually trying it, I updated to head and checked it
out and this is what I got:

postgres=# \df                  List of functionsSchema | Name | Result data type | Argument data types 
--------+------+------------------+---------------------
(0 rows)


Which I admit caught me off guard. The main problem with the above is it
says, "List of functions". It should say, "List of User Defined
Functions" or some such thing.

If I type \dfS I get the usual list of system functions.

I created a user function:

postgres=# create function test() returns integer AS $$select 1$$
language 'SQL';
CREATE FUNCTION

And then used \df

postgres=# \df                  List of functionsSchema | Name | Result data type | Argument data types 
--------+------+------------------+---------------------public | test | integer          | 
(1 row)


I like this behavior. A lot. 

I then created a new schema and a function inside the schema:

postgres=# create schema functions;
CREATE SCHEMA
postgres=# create function functions.test() returns integer AS $$select 1$$ language 'SQL';
CREATE FUNCTION
postgres=# \df                  List of functionsSchema | Name | Result data type | Argument data types 
--------+------+------------------+---------------------public | test | integer          | 
(1 row)

That was a little irritating but I get the point. The schema functions
is not in my search path. So:

postgres=# set search_path to public,functions;
SET
postgres=# \df                  List of functionsSchema | Name | Result data type | Argument data types 
--------+------+------------------+---------------------public | test | integer          | 
(1 row)


The above is broken. If I put functions in my search path and perform a
\df I should get user functions from public and functions.

postgres=# set search_path to functions;
SET
postgres=# \df                    List of functions Schema   | Name | Result data type | Argument data types 
-----------+------+------------------+---------------------functions | test | integer          | 
(1 row)

Performs as expected.

So to me, the patch needs to be fixed. It should search whatever is in
my search path. It should further properly reflect what I am searching
on in its header (List of User Defined Functions).

I do not see any usefulness to searching *ALL* functions except on that
rare occasion where you do them, "Where did I create that function
again?". You can use pg_dump -s for that.

Further I would also be perfectly happy with the following behavior:

\df does nothing but return:

\df <please specify \dfU or \dfS or \dfA)

Where \dfU is users, \dfS is system and \dfA is all (as a compromise).

Sincerely,

Joshua D. Drake



-- 
PostgreSQL - XMPP: jdrake@jabber.postgresql.org  Consulting, Development, Support, Training  503-667-4564 -
http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
 



pgsql-hackers by date:

Previous
From: Andrew Chernow
Date:
Subject: libpq WSACleanup is not needed
Next
From: "Brendan Jurd"
Date:
Subject: Re: pg_dump versus views and opclasses