"Brendan Jurd" <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers