Re: SHOW TABLES

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> I think "LIST COMMENTS ON SYSTEM AGGREGATES" would be an epic
> step forward in usability.

Perhaps. But it would behoove you to come up with a less er...
arcane example. I've been using Postgres a long time, and I can
count the number of times I've needed to see comments on system
aggregates on my hand. With at least four fingers left over.
...
> in the "alphabet soup" paragraph above. I don't think there's
> anything WRONG with letting "\dFp" show text search dictionaries and
> "\dfwS+" list system window functions with additional detail - but I'd
> like an alternative that emphasizes ease of remembering over brevity,
> works in every client, and can be extended in whatever reasonable ways
> the community decides are worth having.
...
I don't know that I'd necessarily remember all those any better, and would
certainly not enjoy typing out:

LIST TEST SEARCH DICTIONARIES

I don't have to remember \dFp - all I have to remember is \?. For the
more common ones that I use day to day and don't have to look up
(\d \dt \df \l etc.) the advantage of a two or three character
string is strong.

(There is some devil's advocate in there - a standard cross client
(and dare I say it, cross RDBMS?) way would be nice)

...
> being powerful rings totally hollow for me. For ordinary, day to day
> tasks like listing all my tables, or looking at the details of a
> particular table, they're great. I use them all the time and would
> still use them even if some other syntax were available. But there is
> no reasonable way to pass options to them, and that to me is a pretty
> major drawback.

Well, there's the rub. You're arguing this from a hacker's persepective,
while the SHOW syntax seems to be overwhelmingly agreed upon to be either
helpful for clueless noobs, or some nice syntactic sugar for average users.

> I'm not sure where to draw the line but implementing a proper shortcut
> interface for cammands is something taht should be done on the client side
> because not every client is the same and the needs of psql might be
> radically different from any other client (like pgadmin or a fancy Web 2.0
> AJAX thingy - those will likely always use custom catalog queries).
> Maybe a differnet way to look at the whole thing is to reconsider our own
> catalogs (anyone remember newsysview?) and add a bunch of views to abstract
> away most of the current complexity for these usecases?

Yep, agreed. Now, if we can just agree to put information_schema in the default
search_path, because nobody enjoys having to type out "information_schema"...

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201007191021
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkxEYDgACgkQvJuQZxSWSsikFwCdGo88Ehdcm8OHi2+VxISTG60Y
b9sAoLsetxcpdMSconsCwj+3Xa1fCCzo
=3aM1
-----END PGP SIGNATURE-----