Re: psql: tab-completion support for COPY ... TO/FROM STDIN, STDOUT, and PROGRAM

From: Kirill Reshke <reshkekirill(at)gmail(dot)com>
To: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql: tab-completion support for COPY ... TO/FROM STDIN, STDOUT, and PROGRAM
Date: 2025-08-28 08:36:00
Message-ID: CALdSSPjE++PBtVLXDnrSaRokff-qBp4WQzib1muveNBeyn20cg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 28 Aug 2025 at 12:22, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> wrote:
>
> > Hi! This tab completion support is indeed very useful. Thanks for
> > working on this.
>
> Thank you for your feedback!
>
> > I spotted potential improvement here: current v5 does not support COPY
> > completion for a pattern I do frequently use:
> > specifying COPY options without WITH clause e.g. "copy yy from
> > '/home/reshke/cpg/csv.csv' <tab>" Is not completed with BINARY, CSV,
> > DELIMITER etc.
>
> This is the old syntax and is supported for backward compatibility
> (commit 923413ac6d3), but I’m not sure it’s worth supporting in tab
> completion. Perhaps it would be better to discuss this point in a
> separate thread.
>

I see your point. However I do not think that old syntax is a show-stopper here.
current psql (on HEAD) has TAB support for archaic patterns like START
<tab> completed with TRANSACTION and ABORT W<tab> completed with WORK.
And I do think that the case I use in COPY (and propose to support
thus) is more frequent than these two. I came across this thread while
looking to support my usecase.
This does not make you obligated to support this in this patch series.
I can even send v5-0004 with this support in the thread if that's
okay.

--
Best regards,
Kirill Reshke

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2025-08-28 08:37:01 RE: Logical Replication of sequences
Previous Message Xuneng Zhou 2025-08-28 08:22:55 Re: Improve read_local_xlog_page_guts by replacing polling with latch-based waiting