Re: Separate psql commands from arguments
От | Gregory Stark |
---|---|
Тема | Re: Separate psql commands from arguments |
Дата | |
Msg-id | 87ve2xdrwh.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Separate psql commands from arguments ("Brendan Jurd" <direvus@gmail.com>) |
Ответы |
Re: Separate psql commands from arguments
|
Список | pgsql-hackers |
"Brendan Jurd" <direvus@gmail.com> writes: > On Sat, Apr 5, 2008 at 10:00 AM, Gregory Stark wrote: >> Regardless of whether we go ahead with this (and I'm not fond of it primarily >> because I want \c& to "work"), > > Okay, but what on earth is "\c&" and what would you expect it to do > when it "works"? I suppose you're connecting to a database, but > somehow I don't think you're talking about a database with the name > "&". Sorry, it was in a patch I submitted a while ago to do concurrent connections. It's supposed to be like & in the shell -- which doesn't require a space before it. I was just explaining in a parenthetical comment the only reason I was personally fond of that feature. It's not an important factor. I think the main point is just that backslash-commands in psql are quirky short strings without a systematic rigorous parser attached. If they were all full words with a simple set of lexer rules and a regular grammer then allowing users to create new commands might be a good idea. But if it's an ad-hoc hand-rolled command loop with short one and two-letter commands that are handled inconsistently then it just seems risky. I tend to think a real cleanup would go something like how GNU --long-options cleaned up traditional unix options. Now most options come in long form by default and short form as a short-cut for frequently used options. Renaming existing commands would be a bit traumatic but we should add new commands with whole-word commands instead of one-character abbreviations. And perhaps add optional abbreviations as short-cuts. In any case the reason the aliases seem like a good idea to me is not to save typing five characters but to save remembering how to put together the magic SQL query I need. That could involve checking the schema of few tables, remembering which functions I need to call and what their calling convention is, etc. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning
В списке pgsql-hackers по дате отправления: