"Peter Eisentraut" <[EMAIL PROTECTED]> 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 -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
