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.
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.
> '&' would stand for "and system objects". We could use '*' but that
> might be confused with a wildcard symbol.
If you insist on treating system object differently than server itself, I'd
prefer for the client not to have me use well known non-alpha keys, which a
lot of shells associate to e.g. jobs processing (bash, csh, lftp, some more
I'm sure).
Regards,
--
dim