Re: [PATCHES] psql slash# command

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Sibte Abbas" <sibtay(at)gmail(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] psql slash# command
Date: 2008-03-30 19:09:20
Message-ID: 27011.1206904160@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

"Sibte Abbas" <sibtay(at)gmail(dot)com> writes:
> On 9/9/07, Sibte Abbas <sibtay(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joris Dobbelsteen 2008-03-30 19:23:58 Re: first time hacker ;) messing with prepared statements
Previous Message sanjay sharma 2008-03-30 18:52:47 Submission of Feature Request : RFC- for Implementing Transparent Data Encryption in Postgres

Browse pgsql-patches by date

  From Date Subject
Next Message NikhilS 2008-03-31 08:36:16 Re: [PATCHES] [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited]
Previous Message Tom Lane 2008-03-30 18:32:35 Re: Consistent \d commands in psql