Based on recent patch feedback from Tom, this has been saved for the
next commit-fest:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---------------------------------------------------------------------------
Tom Lane wrote:
> "Sibte Abbas" <[EMAIL PROTECTED]> writes:
> > On 9/9/07, Sibte Abbas <[EMAIL PROTECTED]> wrote:
> >> Attached is the patch for the TODO item mentioned at
> >> http://archives.postgresql.org/pgsql-hackers/2007-09/msg00352.php
>
> I looked this over and realized that it has little to do with the
> functionality that was so painfully hashed out in the original
> discussion thread here:
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00207.php
>
> As I understood it, the consensus was:
>
> 1. Invent a switch (probably a variable instead of a dedicated \-command)
> that determines whether \s includes command numbers in its output.
>
> 2. Add "\# n" to re-execute command number n.
>
> You've twisted this around into
>
> >> \#: displays the command history. Like \s but prefixes the lines with line
> >> numbers
> >>
> >> \# <line_no>: executes the command(if any) executed at the line specified
> >> by
> >> line_no
>
> This is a serious regression in functionality from what was agreed to,
> because there is no possibility of shoehorning the equivalent of "\s file"
> into it --- you've already decided that any argument is a line number.
>
> It also seems to me to be pretty unintuitive and even dangerous that the
> same \-command would do *fundamentally* different things depending on
> whether it has an argument or not. Especially if one of those things
> involves executing an arbitrary SQL-command.
>
> > The attached patch adds the following new functionality:
> > \#e <lineno>: Will open the command at the given lineno in an editor.
> > \#e with no lineno will behave exactly like \e.
>
> None of that was anywhere in the original discussion; and what pray
> tell is the use of the second variant?
>
> I wonder whether it wouldn't be safer and more convenient if we defined
> '\# n' as pulling command n into the edit buffer, rather than
> immediately executing it. Actual execution is only a <return> away,
> but this definition would allow you to edit the command a bit more
> before you execute it --- including \e to use an editor. It also
> closes the loop in terms of providing some confidence that you typed
> the number you should have typed.
>
> BTW, not related to the original discussion, but I fail to understand
> how anyone finds \s useful interactively, when it doesn't paginate
> its output. Shouldn't we fix that?
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
