"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
