Re: [BUGS] psql history and "-- lines" - Mailing list 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.g.johnston@gmail.com> writes:
>> On Fri, May 5, 2017 at 1:52 PM, Дилян Палаузов <dpa-postgres@aegee.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
>


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs