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

Robert Treat wrote:
> 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

This is how CVS HEAD works now.

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

Yep, same.

> 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.  

I agree, Tom's case where he creates public.sin() is not going to show
without specifying public.sin.  In fact Tom requested months ago that
psql follow the search_path in showing objects, so it is hard to see how
he can consider it wrong now.

> 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. 

The big question is whether '\d* pattern' should exclude looking for
system object, assuming search_path would show the system object, so
'\df cos' would show a function.  I think usability supports this
behavior.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +