| From: | Ishjaap Singh <ishjaap(dot)singh07(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | psql: Don't offer USING INDEX after REPACK (CONCURRENTLY) or (ANALYZE) |
| Date: | 2026-10-31 20:04:10 |
| Message-ID: | CA+Y2BmeqAVC9Vhs+zyXzD+u3DkNF8=zhRs=iTeK5LgFvfuHa8A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi hackers,
In psql on master and REL_19_STABLE, tab completion after a REPACK
option list offers USING INDEX along with the relation names, even
when the options include CONCURRENTLY or ANALYZE. Without a table
name, REPACK USING INDEX processes every eligible table with a
clustering index, which neither option allows, so that suggestion
always fails:
REPACK (CONCURRENTLY) USING INDEX;
ERROR: REPACK (CONCURRENTLY) requires an explicit table name
REPACK (ANALYZE) USING INDEX;
ERROR: cannot execute REPACK (ANALYZE) on multiple tables
The attached patch reads the completed option list and leaves out
USING INDEX when CONCURRENTLY or ANALYZE (also spelled ANALYSE) ends up
enabled. As on the server, the last setting of an option wins, so
"(concurrently off, concurrently)" counts as enabled and
"(concurrently, concurrently false)" does not. USING INDEX is still
offered with no options, with VERBOSE, when both options are off, and
after an explicit table name.
The reader only understands option names and values written as plain
unquoted words. For anything else, such as a quoted name or value or a
signed number, psql keeps the completions it offers today. Handling
those forms too took about 80 more lines, which didn't seem worth it
for tab completion, but I can post that version if people prefer it.
The new cases in 010_tab_completion.pl cover both directions:
USING INDEX left out, and still offered (including when an earlier
CONCURRENTLY is followed by a quoted or unknown value). They fail
without the fix. All psql TAP tests pass on master (61a372b795d) and
REL_19_STABLE (d50c656a8e3), on Linux with GNU readline (I haven't
tried libedit), and pgindent is clean.
The patch is against master. It also applies to REL_19_STABLE, if it
seems worth back-patching there. REPACK is new in 19, so older
branches aren't affected.
This sits next to Baji Shaik's fix for completing ON/OFF inside the
REPACK option list, which Fujii committed in May (e5035950dab). I
could not find a posted fix for this part.
Thanks,
Ishjaap Singh
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-psql-Don-t-offer-USING-INDEX-after-REPACK-CONCURR.patch | application/octet-stream | 7.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lukas Fittl | 2026-10-31 20:21:03 | Re: Unify parallel worker handling for index builds and instrumentation |
| Previous Message | Tom Lane | 2026-10-31 18:35:35 | Re: O(N^3) planning time in choose_plan_name() since 8c49a484e8e |