Re: Separate psql commands from arguments

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

In response to

Responses

Browse pgsql-hackers by date

  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