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