Re: psql command aliases support

"Peter Eisentraut" <peter_e@gmx.net> writes:

> Am Dienstag, 1. April 2008 schrieb Tom Lane:
>> Do we really want such a thing?
>
> Yes!
>
>> The space of backslash command names
>> is so densely populated already that it's hard to imagine creating
>> aliases without conflicting with existing (or future) command names
>> --- as indeed your example does.  It seems like mostly a recipe for
>> confusion.
>
> This is a standard feature and effect on shells.  Shells have even more likely
> commands and conflicts, and still aliases are widely used.  If people are
> concerned about conflicts, they shouldn't use aliases.

I think you're crazy to think shells are more likely to have conflicts. Shells
require a whole token match, not just the first letter.

In other words, any alias *starting with* the letters c, d, e, f, g, h, i,
o, s, w, z would be a conflict. Just for maximum confusion the list of letters
which cause conflicts when capitalized would be entirely different.

Picture a newbie typoing on their \old alias and trying to figure out where
all their data is going... Hopefully they weren't too attached to whatever was
in their "ldd" file yesterday.

I could see it being handy being able to save commonly executed queries and
access them with a shortcut but I think you need to use a separate namespace
from psql's backslash commands. Perhaps `query` or invent a single backslash
command to execute them like "\query current_query". Actually I like that last
idea the most.

One thing to think about is how to pass arguments to the aliases. Csh put us
in the soup by hacking in arguments in a terrible way. As a result quoting in
csh aliases is awful. Even if it's not implemented right away I think we
should figure out what the syntax would be for passing arguments to be
interpolated into the query before backing ourselves into a corner.

I can't imagine much of a use case for being able to alias backslash commands
themselves. They're already ridiculously terse anyways. How many keystrokes
can you possibly save?

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