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-13 20:36:34
Message-ID: 28497.1578947794@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> The file name completion portion of this patch seems to work quite well now.

Thanks for testing!

> 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.

> The good thing is that the new code will behave sensibly with
> select * from "pg_cl<TAB>
> which the old code didn't offer anything on.

Check.

> The problem is that if you have
> create table "test""1" (a int);
> then the new code responds to
> select * from "te<TAB>
> by making that
> select * from "te"
> whereas the old code curiously handled that perfectly.

Right. The underlying cause of both these changes seems to be that
what readline passes to psql_completion is just the contents of the
string, now that we've told it that double-quote is a string quoting
character. So that works fine with 'pg_cl' which didn't need quoting
anyway. In your second example, because we generate possible matches
that are already quoted-if-necessary, we fail to find anything that
bare 'te' is a prefix of, where before we were considering '"te' and
it worked.

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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2020-01-13 22:33:41 Re: BUG #16122: segfault pg_detoast_datum (datum=0x0) at fmgr.c:1833 numrange query
Previous Message Adam Scott 2020-01-13 18:56:32 Re: BUG #16122: segfault pg_detoast_datum (datum=0x0) at fmgr.c:1833 numrange query

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-01-13 20:38:59 Re: Removing pg_pltemplate and creating "trustable" extensions
Previous Message Tom Lane 2020-01-13 20:12:52 Re: benchmarking Flex practices