Re: BUG #16059: Tab-completion of filenames in COPY commands removes required quotes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, steven(dot)winfield(at)cantabcapital(dot)com
Subject: Re: BUG #16059: Tab-completion of filenames in COPY commands removes required quotes
Date: 2020-01-14 01:38:17
Message-ID: 22096.1578965897@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

I wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
>> I have found a weird behavior with identifier quoting, which is not the
>> subject of this patch, but it appears to be affected by it.

> I'll think about how to improve this. Given that we're dequoting
> filenames explicitly anyway, maybe we don't need to tell readline that
> double-quote is a quoting character. Another idea is that maybe
> we ought to refactor things so that identifier dequoting and requoting
> is handled explicitly, similarly to the way filenames work now.
> That would make the patch a lot bigger though.

On reflection, it seems like the best bet for the moment is to
remove double-quote from the rl_completer_quote_characters string,
which should restore all behavior around double-quoted strings to
what it was before. (We have to keep single-quote in that string,
though, or quoted file names fail entirely.)

The only impact this has on filename completion is that we're no
longer bright enough to convert a double-quoted filename to
single-quoted for you, which would be a nice-to-have but it's
hardly core functionality.

At some point it'd be good to undo that and upgrade quoted-identifier
processing, but I don't really want to include such changes in this
patch. I'm about burned out on tab completion for right now.

regards, tom lane

Attachment Content-Type Size
psql-filename-completion-fixes-6.patch text/x-diff 24.9 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2020-01-14 06:03:17 Re: libpq parameter parsing problem
Previous Message Tom Lane 2020-01-14 00:27:05 Re: DROP OWNED CASCADE vs Temp tables

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2020-01-14 01:44:16 Re: Unicode escapes with any backend encoding
Previous Message Tomas Vondra 2020-01-14 01:07:54 Re: Amcheck: do rightlink verification with lock coupling