Re: psql \d* and system objects - Mailing list pgsql-hackers

From Robert Treat
Subject Re: psql \d* and system objects
Date
Msg-id 200903310114.16926.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: psql \d* and system objects  (Bruce Momjian <bruce@momjian.us>)
Responses Re: psql \d* and system objects
Re: psql \d* and system objects
List pgsql-hackers
On Monday 30 March 2009 10:52:47 Bruce Momjian wrote:
> Robert Haas wrote:
> > On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian <bruce@momjian.us> wrote:
> > > Maybe the best we are going to do is to have any pattern supplied to
> > > \d* assume 'S' (include system objects). ?I actually have a patch that
> > > does that, attached. (It is from January so might need adjustment.)
> >
> > That still has the problem that "\df a*" is horribly inconsistent with
> > "\df".  It might be reasonable to assume that if a name without
> > wildcards is given to any \d command, it should display whatever
> > object it finds, user or system - but I can't see doing it for any
> > wildcard at all.
>
> I think you are re-iterating the URL I referenced when I started this
> thread:
>
>     http://archives.postgresql.org/pgsql-hackers/2009-01/msg01443.php
>
> I think the big question is whether the inconsistency (pattern implies
> 'S') is worth accepting for greater usability.
>

Actually I find the iconsistency to hurt usability, which is typically what 
you get with inconsistent interfaces. 

I'm not certain, but I think I would be happier if we did:
\d*    user space objects
\d*S  include system objects

For those that want system only, do 
\d*S  pg_catalog. 
( if you want to argue temp/toast, adjust the search accordingly)

I think the trick to getting this working is to enforce this with search 
patterns *and* tab completion as well. Yes, this means that Tom's desire for 
sin has to become \dfS sin, but this maintains consistency (one of the issues 
I've been running into is finding something via tab completion that I can't 
actually see in the output listing, which is very annoying). 

Further, should you create a function called sin and do \df sin, you should 
only see your function.  This can lead to confusion where you are calling a 
built in function but you dont see it in \df, or you see a different function 
in \df, but I haven't run into that case yet; in the work I've been doing in 
8.4, the above is how I've been wanting it to work, and swapping to \df* to 
see system hasn't been much of an issue.  

BTW, I often do \df *.sin when looking for a function I'm not sure of where it 
lives exactly; this being on current (<=8.3) releases, but many of the 
systems involve a fair number of schemas, that might not be a common 
practice, but perhaps should be. 

-- 
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com


pgsql-hackers by date:

Previous
From: Stuart Bishop
Date:
Subject: Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage?
Next
From: Robert Treat
Date:
Subject: Re: Unexpected Result in Windowing