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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com>, Tim Cross <theophilusx(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: psql UPDATE field [tab] expands to DEFAULT?
Date: 2019-06-20 18:51:50
Message-ID: 19529.1561056710@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

I wrote:
> Nosing around in tab-complete.c, I notice a fair number of other
> places where we're doing COMPLETE_WITH() with just a single possible
> completion. Knowing what we know now, in each one of those places
> libreadline will suppose that that completion is the only syntactically
> legal continuation, and throw away anything else the user might've typed.
> We should probably inspect each of those places to see if that's really
> desirable behavior ... but I didn't muster the energy to do that this
> morning.

I took a closer look and realized that this isn't some magic behavior of
arcane parts of libreadline; it's more like self-inflicted damage. It
happens because tab-complete.c's complete_from_const() is doing exactly
what its comment says it does:

/*
* This function returns one fixed string the first time even if it doesn't
* match what's there, and nothing the second time. This should be used if
* there is only one possibility that can appear at a certain spot, so
* misspellings will be overwritten. The string to be passed must be in
* completion_charp.
*/

This is unlike complete_from_list(), which will only return completions
that match the text-string-so-far.

I have to wonder whether complete_from_const()'s behavior is really
a good idea; I think there might be an argument for getting rid of it
and using complete_from_list() even for one-element lists.

We certainly didn't do anybody any favors in the refactoring we did in
4f3b38fe2, which removed the source-code difference between calling
complete_from_const() and calling complete_from_list() with just one list
item. But even before that, I really doubt that many people hacking on
tab-complete.c had internalized the idea that COMPLETE_WITH_CONST()
implied a higher degree of certainty than COMPLETE_WITH_LIST() with one
list item. I'm pretty sure I'd never understood that.

Both of those functions go back to the beginnings of tab-complete.c,
so there's not much available in the history to explain the difference
in behavior (and the discussion of the original patch, if any, is lost
to the mists of time --- our archives for pgsql-patches only go back to
2000). But my own feeling about this is that there's no situation in
which I'd expect tab completion to wipe out text I'd typed.

Thoughts?

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2019-06-20 19:08:15 Re: Row data is reflected in DETAIL message when constraints fail on insert/update
Previous Message David G. Johnston 2019-06-20 18:20:05 Re: Row data is reflected in DETAIL message when constraints fail on insert/update

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-06-20 18:52:35 Re: Tweaking DSM and DSA limits
Previous Message Stephen Frost 2019-06-20 18:27:15 Re: commitfest application - create patch doesn't work