Re: psql \d* and system objects

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(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +