Re: psql history and "-- lines"

From: Дилян Палаузов <dpa-postgres(at)aegee(dot)org>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: psql history and "-- lines"
Date: 2017-05-06 19:45:08
Message-ID: af1bad5f-56c6-485d-22ba-5bb282d8c137@aegee.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hello,

I expect that psql and the shell, e.g. bash, behave in the same way in
regards to history logs and until-the-current-line comments.

/* such comments
* are out of scope */ SELECT 'here';

In bash, when I start typing a line, that I want to execute later, I put
# in the beginning of the line, and later I go with C-p to that line.

Another possibility to mark the line as comment is with the
insert-comment (M-#) readline command/binding, which prepends # the line
and generates <RET>. In psql M-# puts also # at the beginning of the
line, but this shall be altered to a "--" prefix instead. (To be
precise, it inserts the character associated with comment-begin). Fix:

diff --git a/src/bin/psql/input.c b/src/bin/psql/input.c
--- a/src/bin/psql/input.c
+++ b/src/bin/psql/input.c
@@ -356,6 +356,7 @@ initializeInput(int flags)
/* these two things must be done in this order: */
initialize_readline();
rl_initialize();
+ rl_variable_bind("comment-begin", "--");

useHistory = true;
using_history();

Both bash and psql append to .bash_history / .psql_history, only when
invoked in interactive mode:

echo 'echo "X"'| bash # does not alter .bash_history
echo 'echo "X"'| bash -i # appends to .bash_history
echo "SELECT '1';" | psql # does not amend to .psql_history
psql << Z # does not append to .psql_history
> SELECT '1';
> Z

psql -f whatever.sql # does not add to .psql_history
psql -c "SELECT '1';" # likewise
psql # does add '\i whatever.sql' to .psql_history, not the file content
db=> \i whatever.sql
db=> \q

Concerning the example from system_views.sql, where eight comment lines
precede "CREATE OR REPLACE FUNCTION pg_start_backup": I do not want to
type eight lines of comments in an interactive shell. In the case,
where the comments are yanked from another source, I still want to have
each comment line as separate history entry, as this is consistent with
how comments are logged in bash and I am used to.

Probably /* such things */ can be used to enforce logging with the
subsequent command in contrast to "--".

Regards
Дилян

On 05/06/2017 03:25 AM, Tom Lane wrote:
> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
>> On Fri, May 5, 2017 at 1:52 PM, Дилян Палаузов <dpa-postgres(at)aegee(dot)org>
>> wrote:
>>> Could you plexe alter psql, so that it logs two lines in the history for
>>> the mentioned case?
>
>> It probably should only behave as you suggest in --single-line mode...
>
> I'm not exactly convinced that the proposed change would be an
> improvement. Consider code along the lines of (actual example
> from system_views.sql):
>
> --
> -- Redeclare built-in functions that need default values attached to their
> -- arguments. It's impractical to set those up directly in pg_proc.h because
> -- of the complexity and platform-dependency of the expression tree
> -- representation. (Note that internal functions still have to have entries
> -- in pg_proc.h; we are merely causing their proargnames and proargdefaults
> -- to get filled in.)
> --
>
> CREATE OR REPLACE FUNCTION
> pg_start_backup(label text, fast boolean DEFAULT false, exclusive boolean DEFAULT true)
> RETURNS pg_lsn STRICT VOLATILE LANGUAGE internal AS 'pg_start_backup'
> PARALLEL RESTRICTED;
>
> Would you really want each of those -- lines to be their own history
> entry?
>
> Another angle to think about is /* ... */ comments, which you really
> can't break into separate lines without creating a syntactically-invalid
> mess. That type of comment also creates the possibility of input like
>
> /* foo
> * bar */ select ...
>
> There isn't any very nice way to separate this comment from the SQL query
> for history purposes.
>
> In my own usage, I think having leading comments being treated as
> part of the SQL command is a good thing --- they're sort of a unit,
> in most cases.
>
> regards, tom lane
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Дилян Палаузов 2017-05-06 20:31:05 Re: Postgresql and Clang Static Analyzer
Previous Message Noah Misch 2017-05-06 19:02:46 Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression