Thread: failure and silence of SQL commands

failure and silence of SQL commands

From
"John Payne"
Date:

In my own defense: The function of any user interface should be to help the user perform a task.  In this case, the user interface is clearly not helpful.  I maintain that to some degree “the customer is always right”.  The change from -> to => was so subtle that I didn’t notice it.  I’m sure that a very close reading of the documentation would have eventually solved my problem, but the syntax is really not obvious here.  It took me a while to realize that there are two kinds of commands: internal commands and SQL commands – the documentation helped me there.  But then the fact that internal commands must start with a backslash and end without a semicolon, whereas SQL commands must start without a backslash and end with a semicolon was not immediately clear.  No matter how stupid Leif or others may think I am, I guarantee you that there will be other people  in my shoes in the future.  Any really great user interface makes it possible for the user to figure out how to get the behavior he or she wants, *without* reading the manual.   

 

Again, I do thank you all for your help.

 

John

 

John Payne
POST Staff Scientist and US Coordinator
www.postcoml.org

Tel. (206) 463-3404

 

Re: failure and silence of SQL commands

From
Leif Biberg Kristensen
Date:
On Thursday 28 April 2011 21:28:12 John Payne wrote:
> In my own defense: The function of any user interface should be to help the
> user perform a task.  In this case, the user interface is clearly not
> helpful.  I maintain that to some degree "the customer is always right".
> The change from -> to => was so subtle that I didn't notice it.  I'm sure
> that a very close reading of the documentation would have eventually solved
> my problem, but the syntax is really not obvious here.  It took me a while
> to realize that there are two kinds of commands: internal commands and SQL
> commands - the documentation helped me there.  But then the fact that
> internal commands must start with a backslash and end without a semicolon,
> whereas SQL commands must start without a backslash and end with a
> semicolon was not immediately clear.  No matter how stupid Leif or others
> may think I am, I guarantee you that there will be other people  in my
> shoes in the future.  Any really great user interface makes it possible
> for the user to figure out how to get the behavior he or she wants,
> *without* reading the manual.

psql is an incredibly powerful tool, but like most command line utilities of
the Unix tradition, the interface *will* appear terse to a novice. We've all
been there, and have invariably been told to RTFM. Calling that tradition
"pathological" is not a good way to make friends ;)

Yes, the change from => to -> is subtle. That's the way most of us prefer it,
once we're past the initial learning curve. In addition, the prompt may change
to (> whenever you have an open parenthesis carry over to the next line. I find
that very helpful.

Ending an SQL query with a semicolon is per the SQL standard, and the reason
is quite obvious; it would be very hard to enter multiline queries unless you
have an unequivocal way of telling the parser that you're finished. It will
soon become second nature as you grow aquainted with psql.

regards, Leif.