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-04 23:00:14
Message-ID: 871w5lfcox.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:

> +1 for dropping this quirk. And, if there are no objections (or other
> takers), I volunteer to write a patch.

Regardless of whether we go ahead with this (and I'm not fond of it primarily
because I want \c& to "work"), I think we would still be better off keeping
the aliases in a separate namespace from psql commands and having an explicit
command for calling them.

I also don't see any point in allowing aliases which call other psql commands.
psql is not a particularly nice and well defined interface and it would just
make it that much more complex and confusing.

I still see it much cleaner and much clearer for people reading the script to
have something like

\query dpkg perl-base*

Than to have something like

\dpkg perl-base*

which looks like it might be related to \dp in some way the way (like how \dFp
is related to \dF).

It would also mean that if you try to run a query which doesn't exist you
won't accidentally type a real command or get a "command not found" error.

--
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 Alvaro Herrera 2008-04-04 23:02:37 Re: Separate psql commands from arguments
Previous Message Tom Lane 2008-04-04 22:57:01 Re: Garbage pad bytes within datums are bad news