Proposal for psql wildcarding behavior w/schemas

So far as I recall, no one's really taken up the challenge of deciding
how psql's various \d commands should work in the presence of schemas.
Here's a straw-man proposal:

1.  A wildcardable pattern must consist of either "namepattern" or
"namepattern.namepattern".  In the first case we match against all names
visible in the current search path.  In the second case, we consider all
names matching the second part of the pattern within all schemas
matching the first part, without regard to search path visibility.
(For the moment, anyway, patterns containing more than one dot are an
error.)

2.  I'd like to switch over to using explicit wildcard characters.
There are presently some cases where psql assumes an implicit "*" at the
end of a name pattern, but I find this surprising.  Seems like it would
be more consistent if foo meant foo, and you had to write "foo*" to get
a wildcard search.

3.  As for the specific wildcard characters, I propose accepting "*"
and "?" with the same meanings as in common shell filename globbing.
This could be extended to include character classes (eg, [0-9]) if
anyone feels like it.  Following shell practice rather than (say)
regexp or LIKE rules avoids problems with dot and underscore, two
characters that we definitely don't want to be pattern match characters
in this context.

4.  The wildcard characters "*" and "?" are problematic for \do
(display operators), since they are valid characters in operator names.
I can see three possible answers to this:   A.  Don't do any wildcarding in operator searches.   B.  Treat "*" and "?"
aswildcards, and expect the user to quotethem with backslashes if he wants to use them as regularcharacters in an
operatorsearch.   C.  Treat "*" and "?" as regular characters in operator search,and let "\*" and "\?" be the wildcards
inthis context.
 
A is the current behavior but lacks functionality.  C might be the most
convenient once you got used to it, but I suspect people will find it
too confusing.  So I'm leaning to B.

Comments, better ideas?
        regards, tom lane