Re: psql UPDATE field [tab] expands to DEFAULT?

From: Tim Cross <theophilusx(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: psql UPDATE field [tab] expands to DEFAULT?
Date: 2019-06-18 00:52:44
Message-ID: CAC=50j_-9-m8Aejh62gBy_Te_KXjAyaGOvZzScvNyYL811vNvg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Tue, 18 Jun 2019 at 10:39, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Tim Cross <theophilusx(at)gmail(dot)com> writes:
> > On Tue, 18 Jun 2019 at 09:34, Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com> wrote:
> >> Thanks Adrian, though I wasn't really seeking tips for column names. I
> >> was instead trying to understand whether this particular tab expansion
> was
> >> intentional and considered useful, and if so what that usefulness was,
> >> because it's rather escaping me!
>
> > Have to say, I fid that behaviour unusual as well.
>
> I don't think it's intentional. A look into tab-complete.c shows that it
> makes no attempt to offer completions beyond the "=" part of the syntax;
> so there's room for improvement there. But then what is producing the
> "DEFAULT" completion? After looking around a bit, I think it's
> accidentally matching the pattern for a GUC "set" command:
>
> else if (TailMatches("SET", MatchAny, "TO|="))
> {
> /* special cased code for individual GUCs */
> ...
> else
> COMPLETE_WITH("DEFAULT");
> }
>
> So perhaps that needs to look more like this other place where somebody
> already noticed the conflict against UPDATE:
>
> else if (TailMatches("SET|RESET") && !TailMatches("UPDATE", MatchAny,
> "SET"))
> COMPLETE_WITH_QUERY(Query_for_list_of_set_vars);
>
> More generally, though, I'm inclined to think that offering DEFAULT
> and nothing else, which is what this code does if it doesn't recognize
> the "GUC name", is just ridiculous. If the word after SET is not a known
> GUC name then we probably have misconstrued the context, as indeed is
> happening in your example; and in any case DEFAULT is about the least
> likely thing for somebody to be trying to enter here. (They'd probably
> have selected RESET not SET if they were trying to do that.)
>
> regards, tom lane
>

Given that without adding a full blown sql parser in order to identify
legitimate candidates following a '=' in an update statement, my suggestion
would be to refine the rules so that no completion is attempted after the
=. Would rather have tab do nothing over tab replacing what I've already
typed with 'default'.

--
regards,

Tim

--
Tim Cross

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sourav Majumdar 2019-06-18 08:06:25 Re: Connection refused (0x0000274D/10061)
Previous Message raf 2019-06-18 00:47:28 Re: Inserts restricted to a trigger

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-06-18 00:52:56 Re: Fix typos and inconsistencies for v11+
Previous Message Tom Lane 2019-06-18 00:39:21 Re: psql UPDATE field [tab] expands to DEFAULT?