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: