--On Freitag, April 04, 2008 05:04:04 +1100 Brendan Jurd
<[EMAIL PROTECTED]> wrote:
For everyone else who hasn't read the original discussion on -patches,
here's a link into the archives:
<http://archives.postgresql.org/pgsql-patches/2008-04/msg00005.php>
On Fri, Apr 4, 2008 at 4:19 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
Yeah, the fundamental difference between the backslash command situation
and aliases in shells and suchlike is that, because we've historically
allowed no space between command name and argument, it's not that easy
to tell what string ought to be compared against alias names.
I think that an alias facility would only be acceptably safe if we
disallowed that syntax (ie, start to *require* a space between command
and args). Are we ready to do that?
Okay, the more we talked about that, the more i got that feeling, too.
As far as i know, this behaviour isn't documented anywhere. In fact,
the manual denies its existence:
"The format of a psql command is the backslash, followed
immediately by a command verb, then any arguments. The arguments are
separated from the command verb and each other by any number of
whitespace characters."
Not only there, the code itself doesn't encourage the use of this syntax
(src/bin/psql/command.c), too:
/*
* If the command was not recognized, try to parse it as a
one-letter
* command with immediately following argument (a
still-supported, but
* no longer encouraged, syntax).
*/
(unless you interpret "any number" to include zero, but that's quite a
stretch in this context)
For what it's worth, I've been using Postgres actively for about five
years, and I've not once suspected that it was possible to omit the
space between a psql command and its argument.
The idea of writing the command and its arguments in one word is so
completely bizarre to me that I can't imagine anyone even trying it
casually to see if it works. Although it is likely that some people
have stumbled upon it accidentally via typos, it's hard to imagine
them wanting to use it in any kind of pratical application.
+1 for dropping this quirk. And, if there are no objections (or other
takers), I volunteer to write a patch.
Here's a quick and dirty patch which removes the responsible code from psql
(maybe not enough, but short testing shows it's working). Sorry for the
unified diff....
+1, too. I advised people not to use that syntax for years now, maybe we're
in luck and everyone else was doing the same ;)
--
Thanks
Bernddiff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 1392972..c1194c2 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -90,30 +90,6 @@ HandleSlashCmds(PsqlScanState scan_state,
/* And try to execute it */
status = exec_command(cmd, scan_state, query_buf);
- if (status == PSQL_CMD_UNKNOWN && strlen(cmd) > 1)
- {
- /*
- * If the command was not recognized, try to parse it as a one-letter
- * command with immediately following argument (a still-supported, but
- * no longer encouraged, syntax).
- */
- char new_cmd[2];
-
- /* don't change cmd until we know it's okay */
- new_cmd[0] = cmd[0];
- new_cmd[1] = '\0';
-
- psql_scan_slash_pushback(scan_state, cmd + 1);
-
- status = exec_command(new_cmd, scan_state, query_buf);
-
- if (status != PSQL_CMD_UNKNOWN)
- {
- /* adjust cmd for possible messages below */
- cmd[1] = '\0';
- }
- }
-
if (status == PSQL_CMD_UNKNOWN)
{
if (pset.cur_cmd_interactive)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
