
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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).

I'll assume we are switching to the "explicit wildcard" system for this. 
(I think the proposed *? wildcards are a great idea). Basically, for 
those functions (esp. \d) that can return a list or a single item, 
the wildcard indicates that we want a list, and a lack of wildcard 
indicates we want a single item.

\d foo.baz    Shows details about the table bar in the schema foo

\d baz        Attempts to find a visible baz in the schemas, shows first 
              one that matches.

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

\d *.baz*     Same as above

\d baz.*      Shows all tables in the baz schema

\d foo.baz*   Shows all tables starting with "baz" in the "foo" schema

\d *.baz      Similar to \d baz, but the wildcard forces all matches 
              to be shown.

\d foo*.baz   Shows all tables named "baz" in schemas staring with "foo"

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

\d *oo.       Matches all tables in schemas ending in "oo"

\d *oo.*      Same as above - a plain * on either side of the dot is
              usually superfluous, except that it forces a list of matches.


The only one I have a problem with is the '\d baz' which some may argue should 
continue the current behavior and return details about the first "baz" 
table it encounters. On the other hand, people really need to start thinking 
about schemas and the consequences of having more than one table named 
"baz". Still, typing in the schema could get tedious very quickly. Perhaps it 
should only return a list if more than one table was found, otherwise it 
will return information about that table.

The good thing about the above is that \d and \dt will actually have the 
same functionality. The current behavior can be a bit confusing, in that 
some functions have implicit wildcards (\dt and friends) and some do 
not (\d).

Greg Sabino Mullane  greg@turnstep.com
PGP Key: 0x14964AC8 200208091849

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iD8DBQE9VEb6vJuQZxSWSsgRAsHNAKDCXz4vUY1A79EaVmfPIfcNS7VyxgCaA5Tx
HrNmY0vITbb2G1fZFBCPgBM=
=qhYp
-----END PGP SIGNATURE-----



Fri,  9 Aug 2002 22:50:10 -0000
"Greg Sabino Mullane" <greg@turnstep.com>
Re: Proposal for psql wildcarding behavior w/schemas
"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

Sat, 10 Aug 2002 00:49:17 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Proposal for psql wildcarding behavior w/schemas 