Re: [PROPOSAL] bracketed-paste support for psql

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Geoff Winkless <pgsqladmin(at)geoff(dot)dj>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PROPOSAL] bracketed-paste support for psql
Date: 2017-12-29 17:01:56
Message-ID: 20171229170156.4nwcbclsyzsdkl5h@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote:
> On 12/15/17 11:22, Geoff Winkless wrote:
> > It occurred to me the other day while people were talking about
> > pasting blocks of text creating problems, especially with tabs, that
> > xterm bracketed-paste support (also works in at least putty and
> > probably others) that would block curses handling and just paste as-is
> > would be a useful (and I'm guessing relatively simple) thing to add.
>
> You need to put
>
> set enable-bracketed-paste on
>
> into ~/.inputrc, then it works.

Thanks for mentioning this -- I didn't know if, and it's a nice feature.
I've been trying it for a few days and it seems to work pretty well.

There is a problem with backslash commands, though: the parser seems to
search for arguments to the commands all the way to the end of the
buffer rather than the end of the line, so if you paste this:

\d tab1
select * from tab1;

it fails in this seemingly very stupid way:

alvherre=# \d tab1
select * from tab1;
Table "public.tab1"
Column │ Type │ Collation │ Nullable │ Default
────────┼─────────┼───────────┼──────────┼─────────
a │ integer │ │ │

\d: extra argument "select" ignored
\d: extra argument "*" ignored
\d: extra argument "from" ignored
\d: extra argument "tab1;" ignored

It would be useful to stop looking for arguments at EOL. This behavior
is at odds with how backslash commands work elsewhere.

However, if you don't have a table named 'tab1', processing stops right
there:

alvherre=# \d tab1
select * from tab1;
Did not find any relation named "tab1".
alvherre=#

I think this would be fine in ON_ERROR_STOP mode, but I have that turned
off here, so it looks like a bug to me.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-12-29 17:19:16 Re: Possible hole in Windows directory restrictions?
Previous Message Jack Christensen 2017-12-29 16:55:25 Re: Possible hole in Windows directory restrictions?