Re: Proposal for psql wildcarding behavior w/schemas - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal for psql wildcarding behavior w/schemas
Date
Msg-id 20883.1028954957@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal for psql wildcarding behavior w/schemas  ("Greg Sabino Mullane" <greg@turnstep.com>)
List pgsql-hackers
"Greg Sabino Mullane" <greg@turnstep.com> writes:
> Here's my thoughts on the matter:
> More than one period throws an error (something pleasant, mentioning 
> that we do not quite support cross-database queries yet).

The just-committed implementation doesn't throw an error, but silently
discards name fragments to the left of the last two --- for example,
foo.bar.baz is silently treated as bar.baz.  This could probably be
improved, but I haven't quite figured out how psql deals with error
recovery...

Otherwise I agree with your comments, except for

> \d baz*       Shows all tables starting with "baz", in all available schemas

Make that "shows visible tables whose names begin with baz".  There is
a subtle difference.

> \d *.baz*     Same as above

This shows tables whose names begin with baz, in any schema in the
database --- without regard to visibility.

> \d *.*        Same as plain old \d (which is actually a special case now)

\d without an argument is still a special case: it transforms to \dtvs
with no argument.  Other than that little usability kluge, the general
rule is that for any object-type x, \dx is the same as \dx *, which is
*not* the same as \dx *.* ... the former shows all visible objects, the
latter all objects in the database.

> The current behavior can be a bit confusing, in that some functions
> have implicit wildcards (\dt and friends) and some do not (\d).

As of cvs tip, all the \d family take wildcards.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Wanted: RelationIsVisible interface
Next
From: Tom Lane
Date:
Subject: Re: Proposal: stand-alone composite types