Re: Separate psql commands from arguments

"Peter Eisentraut" <peter_e(at)gmx(dot)net> writes:

> But other people do want to use it. If it is too confusing for you, don't use
> it. That's what's nice about this feature: If you don't use it, it doesn't
> affect you at all.

Ah but I would use it. In particular the query I found myself writing *all*
the time over and over again in Oracle was:

select count(*),n from (select count(*) as n from <tab> group by <col>) group by n

I can type it out now from finger-memory without even thinking about it. I
would have killed for a macro facility like this where I could just do

\query dist users city

and get the frequency distribution of cities in the users table.

I don't think

\dist users city

is really much of a savings and I think it would be a huge source of confusion
that it's unrelated to the \di \ds and \dt commands. And I might well not know
about those commands and define a \di alias myself, only to try using \di
later. Or worse, define a \dx command and have it fail mysteriously in Pg 8.4.

Also, people do share stuff, even (or especially!) cute short cuts like this.
In the worst case witness Redhat's insistence on putting those damn aliases in
the standard dotfiles for example.

And plenty of sites have aliases in their root dotfiles which are part of
their site operating procedures. Picture having to explain how to use psql to
new hires including the site-specific aliases which you've built up over time
when some of those aliases conflict or have similar names to built-in
commands. A new user has no way to figure out which ones will do what type of
action.

Sure in the majority of cases it doesn't really matter how awkwardly
intermingled with the \commands the interface is. But it doesn't make much
sense to design around the cases where the design doesn't matter -- that way
lies, uhm, other databases. Let's keep in mind when designing the feature the
most long-term use where the design matters most rather than the case where it
matters least.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning