From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Brendan Jurd" <direvus(at)gmail(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>, "Bernd Helmle" <mailings(at)oopsware(dot)de>, "Peter Eisentraut" <peter_e(at)gmx(dot)net> |
Subject: | Re: Separate psql commands from arguments |
Date: | 2008-04-05 01:14:38 |
Message-ID: | 87ve2xdrwh.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Brendan Jurd" <direvus(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-04-05 01:17:10 | Re: modules |
Previous Message | Bruce Momjian | 2008-04-05 01:14:06 | Re: Patch queue -> wiki |