Tom Lane wrote:
> 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.)
I like this.
> 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.
Agree
>
> 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.
Agree again
>
> 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 "?" as wildcards, and expect the user to quote
> them with backslashes if he wants to use them as regular
> characters in an operator search.
> C. Treat "*" and "?" as regular characters in operator search,
> and let "\*" and "\?" be the wildcards in this 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.
I would definitely vote for B.
Joe