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

From Bruce Momjian
Subject Re: FWD: Re: Updated backslash consistency patch
Date
Msg-id 200901201618.n0KGIKG12375@momjian.us
Whole thread Raw
In response to Re: FWD: Re: Updated backslash consistency patch  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
Dimitri Fontaine wrote:
-- Start of PGP signed section.
> Le mardi 20 janvier 2009, Bruce Momjian a ?crit?:
> > Robert Haas wrote:
> > > > Here is what I hope is a consensus patch.  It adds 'A' to show all
> > > > objects, including system ones.  It turns out that this is how 'S'
> > > > works now in CVS, but 'S' is unclear because it suggests just system
> > > > objects; 'A' for show 'all' objects seems clearer.
> > >
> > > I think it's probably fine for "S" to mean "include system objects"
> > > rather than "show only system objects".  Everyone should be relatively
> > > used to "S" by now; I think it's less confusing to keep the same
> > > letter even if the behavior has been adjusted somewhat.  Though others
> > > may disagree?
> 
> I still think that given a pattern, psql commands should simply mimic whatever 
> is the server way of using search_path. I'd really like \df foo and \d foo to 
> follow the same rules as my production queries wrt to how to find objects 
> when I'm too lazy to schema qualify their name.
> 
> Now, it's been advocated for the sake of simplicity to have with-pattern and 
> without-pattern options behave roughly the same way. I can't find it 
> difficult to explain the two behaviours here, all the more when looking at 
> current \d and \dt differences.

The \d and \dt differences are fixed/gone in current CVS.

> What I'd like to propose is for \df without pattern to behave exactly like \df
> with pattern, *including* wrt to ordering the output. Functions listed in 
> search_path order, pg_catalog implicitly part of it, but as its *last* 
> element. Or whatever server object lookup code sayth.

I personally liked the idea of searching pg_catalog for a pattern, but
what turned me against it was this behavior:
\dlong list of user tables

and then the user wants to see just the tables that begin with 'p':
\d p*list of system and user tables that start with 'p'

All of a sudden they see many system tables.  It is hard to call that
behavior logical or expected.  One unusual approach would be to search
pg_catalog only when a _non-wildcard_ pattern was supplied, so:
\d p*

would show user tables beginning with 'p', but:
\d pg_class

would find the 'pg_class' table that is the search path, typically from
pg_catalog.  It might be a little awkward to document, but might be the
most acceptable solution.  The very good argument _against_ this
solution is that:
\d pg_class*

would show no rows while:
\d pg_class

would show the pg_catalog entry.  This is also odd and unexpected, which
led me to just having people use 'S' when they want pg_catalog involved.

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


pgsql-hackers by date:

Previous
From: Jeroen Vermeulen
Date:
Subject: Re: libpq WSACleanup is not needed
Next
From: Andrew Chernow
Date:
Subject: Re: libpq WSACleanup is not needed