Re: SHOW TABLES

On 07/17/2010 04:02 PM, Robert Haas wrote:
> On Jul 16, 2010, at 11:02 PM, Stephen Frost<sfrost@snowman.net>  wrote:
>> * Robert Haas (robertmhaas@gmail.com) wrote:
>>> Why must the backslash commands be more powerful than any alternative
>>> we might come up with?
>>
>> Because they encode alot of information in a character- something which
>> is next to impossible to do in "english".
>
> I don't think that "terse" and "powerful" are the same thing. One of my beefs with the backslash commands is that the
syntaxis not cleanly extensible.  We have S and + as postfix modifiers, and that's fairly comprehensible, but as soon
asyou think about going much further with it, it starts to seem like alphabet soup.
 
>
> In fact, we're pretty close to alphabet soup already. Without looking at the help, what does \db do?  What are the
commandsto list casts, conversions, and comments, respectively?  What syntax would you propose for a backslash command
tolist comments, but only those on a certain object type?  If you don't think we should have a backslash command for
that,can you write an SQL query that lists comments on built-in aggregates in less than two minutes?  How many people
doyou think can do it at all?
 
>
> I think "LIST COMMENTS ON SYSTEM AGGREGATES" would be an epic step forward in usability.


uh oh - that actually sounds like a big step backwards to me - it's 
inventing extremely verbose pseudo english syntax for something that we 
currently do with a trivial and easy to remember backslash command.
Do we really need to invent a completely new language for this?
Once you extend that syntax to what you are proposing (ie provide a way 
to filter like "LIST COMMENTS ON SYSTEM AGGREGATES WITH NUMERIC INPUT") 
you basically reinvented a query language - ever heard of SQL or QUEL?
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?


Stefan