From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Brendan Jurd <direvus(at)gmail(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: FWD: Re: Updated backslash consistency patch |
Date: | 2009-01-15 17:49:59 |
Message-ID: | 1232041799.21285.8.camel@jd-laptop.pragmaticzealot.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2009-01-15 at 12:36 -0500, Tom Lane wrote:
> "Brendan Jurd" <direvus(at)gmail(dot)com> writes:
> > Most people wanting to learn about which system functions are
> > available will be surely be going to the manual, not using \df?
>
> I think people use \df all the time to check the argument list, verify
> whether they remember the function name correctly, etc. It's not for
> "learning about" stuff you never heard of, it's for remembering details
> (as indeed is the usage for user-defined functions too).
Perhaps the way to solve this problem is to change the way the output is
rendered. E.g;
\df output wraps at 1024x768 which greatly limits usability as a whole.
I hadn't noticed this until today as my workstation video card exploded
and I have a temporary one that can't do more than 1024x768 with linux.
Dropping the return type from the default output would solve this
problem I think (use + to get the return type).
More importantly why not just have it so \df sorts like this:
1. session users functions first
2. public functions second
3. pg_catalog functions last
Sincerely,
Joshua D. Drake
>
> regards, tom lane
>
--
PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-15 17:50:24 | Re: FWD: Re: Updated backslash consistency patch |
Previous Message | Bruce Momjian | 2009-01-15 17:43:06 | Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION |