Thread: Re: [PATCHES] Friendly help for psql
Alvaro Herrera wrote: > To avoid the usage of unadorned "help" (which I don't think is going to > ever cause conflicts with a SQL command but perhaps it's better to be > prepared), one idea would be to respond with "please execute \help > instead", and then \help would emit the verbose output. Perhaps > eventually we could adorn it with "\help category", etc. Uh, imagine: test=> SELECT * from pg_classtest-> help Technically 'help' is now an alias for 'pg_class'. Are you suggesting supporting 'help' in this usage? People were saying they forget semicolons, so this 'help' usage is quite possible. We don't want to hear "Why doesn't 'help' work sometimes?" I think the fundamental problem is that most programs, like ftp, have a predefined set of single-line commands, while we have an SQL 'language' that can be multi-line and has no special markings in psql. In fact the special marking is for help and psql-commands using backslash. Supporting 'help' in psql seems like a very slippery slope. We are very tight in defining when an entry is psql and when it is SQL and this weakens that. What would be interesting would be if the _server_ could send back some message about "Use the help facility of your client application" but it would have to have a trailing semicolon; unlikely. :-( -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > Uh, imagine: > > test=> SELECT * from pg_class > test-> help > > Technically 'help' is now an alias for 'pg_class'. Are you suggesting > supporting 'help' in this usage? People were saying they forget > semicolons, so this 'help' usage is quite possible. We don't want to > hear "Why doesn't 'help' work sometimes?" I don't think we have to worry about supporting that case. We only support it when the command begins with "help". No ambiguity with SQL to worry about. Don't forget that ctrl-c resets a query as well, so the above situation is not as dire as it may appear to the uninitiated user. > Supporting 'help' in psql seems like a very slippery slope. We are very > tight in defining when an entry is psql and when it is SQL and this > weakens that. Does not seem slippery to me, seems a simple, one-time fix that replaces a syntax error with a helpful message. As the instigator of this discussion, I can assure you I have no plans for anything other than "help". It's simple, standard, and points you to anything else you may need or want to do. > What would be interesting would be if the _server_ could send back some > message about "Use the help facility of your client application" but it > would have to have a trailing semicolon; unlikely. :-( Now THAT would be a bad mangling of SQL and non-SQL. We'll pretend you didn't suggest that one. :) - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200801281451 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFHnjJgvJuQZxSWSsgRA8mMAJ4jzlrwYDVguUNt2yAwMTXMvV1S3QCg+SaF n8ybxb/KbGBxW9aouZGpzaY= =igJU -----END PGP SIGNATURE-----
Bruce Momjian <bruce@momjian.us> writes:
> Alvaro Herrera wrote:
>> To avoid the usage of unadorned "help" (which I don't think is going to
>> ever cause conflicts with a SQL command but perhaps it's better to be
>> prepared), one idea would be to respond with "please execute \help
>> instead", and then \help would emit the verbose output. Perhaps
>> eventually we could adorn it with "\help category", etc.
> Uh, imagine:
> test=> SELECT * from pg_class
> test-> help
You didn't read the patch: it would recognize "help" only when the input
buffer is empty. The only thing it's assuming is that no SQL command
will ever *begin* with the word "help".
regards, tom lane