| 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-19 14:39:24 |
| Message-ID: | 6787.1560955164@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
[ moving thread to -hackers ]
So I propose the attached patch for fixing the clear bugs that have
emerged in this discussion: don't confuse UPDATE ... SET ... with
GUC-setting commands, and don't offer just DEFAULT in contexts where
that's unlikely to be the only valid completion.
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.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| fix-bogus-SET-completions.patch | text/x-diff | 1.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Job | 2019-06-19 16:06:09 | Problem with row-level lock |
| Previous Message | Achilleas Mantzios | 2019-06-19 08:46:43 | Re: unexpected behavior with pglogical -- bug? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2019-06-19 14:53:41 | Re: New EXPLAIN option: ALL |
| Previous Message | Rui Hai Jiang | 2019-06-19 14:27:03 | Re: How to produce a Soft Block case of Deadlock Detection? |