psql slash# command

On 9/9/07, Sibte Abbas <sibtay@gmail.com> wrote:

Attached is the patch for the TODO item mentioned at
http://archives.postgresql.org/pgsql-hackers/2007-09/msg00352.php

The command has the following synopsis:

\#: 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

regards,
--
Sibte Abbas

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.

Example:
=====

psql> \#

199: create or replace function foo() returns integer as $$
begin
return 10;
end;
$$language 'plpgsql';

200: select version();

201: select * from foo();

\# 200
<select version() is executed>

psql> \#e 199
<the contents of lineno 199 are opened in the editor>

Definitely not for 8.3, however I hope that it can be queued for 8.4.

thanks,
--
Sibte Abbas

This has been saved for the 8.4 release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Sibte Abbas wrote:

On 9/9/07, Sibte Abbas <sibtay@gmail.com> wrote:

Attached is the patch for the TODO item mentioned at
http://archives.postgresql.org/pgsql-hackers/2007-09/msg00352.php

The command has the following synopsis:

\#: 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

regards,
--
Sibte Abbas

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.

Example:
=====

psql> \#

199: create or replace function foo() returns integer as $$
begin
return 10;
end;
$$language 'plpgsql';

200: select version();

201: select * from foo();

\# 200
<select version() is executed>

psql> \#e 199
<the contents of lineno 199 are opened in the editor>

Definitely not for 8.3, however I hope that it can be queued for 8.4.

thanks,
--
Sibte Abbas

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

"Sibte Abbas" <sibtay@gmail.com> writes:

On 9/9/07, Sibte Abbas <sibtay@gmail.com> 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

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" <sibtay@gmail.com> writes:

On 9/9/07, Sibte Abbas <sibtay@gmail.com> 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 <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Sun, Mar 30, 2008 at 3:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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 patch implements the specification described here:

http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php

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 made sense to assume anything following a \# to be a number, since "#"
here denotes a number. However in order to prevent from bad input, there is
a check in the get_hist_entry() function.

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?

The above mentioned link contains definitions for both of these. Also the
second variant here is just for completeness sake.

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.

This makes more sense and also appears to be much safer. I will start
modifying the patch as per this approach now.

regards,
-- Sibte Abbas

On Thu, Apr 3, 2008 at 7:54 PM, Sibte Abbas <sibtay@gmail.com> wrote:

On Sun, Mar 30, 2008 at 3:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:<http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php&gt;

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.

This makes more sense and also appears to be much safer. I will start
modifying the patch as per this approach now.

Based on your feedback I have modified the attached patch as follows:

1) \# n opens command n into the edit buffer.

2) A new psql variable; SHOW_LINE_NO is added, which is consulted by the \s
command.
If it is set, \s prefixs each line of its output with an incrementing
line number.

regards,
-- Sibte Abbas