Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u2xf2-008MOg-B9 for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Apr 2025 19:34:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1u2xf0-00Gi8W-KH for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Apr 2025 19:34:02 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u2xf0-00Gi8O-8C for pgsql-hackers@lists.postgresql.org; Thu, 10 Apr 2025 19:34:02 +0000 Received: from mail-ot1-x331.google.com ([2607:f8b0:4864:20::331]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u2xex-004ZmF-3B for pgsql-hackers@postgresql.org; Thu, 10 Apr 2025 19:34:02 +0000 Received: by mail-ot1-x331.google.com with SMTP id 46e09a7af769-72c1419f73eso1169501a34.1 for ; Thu, 10 Apr 2025 12:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744313638; x=1744918438; darn=postgresql.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RIceJ9Uwp70VqtMeZB+Zsz2GVzBZd87sBfgFM/kbzKU=; b=OLYW3jcw2dIeYPxWRqfzH3jRa2zNTo3x/XuTrZ7N1OmYoKBmmP0fs5ArC2qqcOddRv F/boEsB2OmaFL+z5GaoJ4rZzBjwbS5Nlmm2BjONDzQafFvdQCKLpgBVgXxVTg6LwApEu cNXIMQwInbUJg038WkZHdxgbXXxDKittArvjF2C/2QTcisIc7f60ADV5RBCCQ4g8NlAt gcA+9jXqV1Csy9uxufvE3naCKYUm5CO3uv8j6Tnlo6kA5crg2vvh3HfvYo/E6qlRiz5S pj2aBL/SfS4cRKULIaHN/XDPGJUCHwM3s5N3swjWQQF2QEj4A53SAkWkS1gf87B0Mi1L ae2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744313638; x=1744918438; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RIceJ9Uwp70VqtMeZB+Zsz2GVzBZd87sBfgFM/kbzKU=; b=iHan9p7ctKpOkU43wXiNgARvxlDWY6JL7+XnjG2pFfnd09WMd4TcOoVf7BeQlI8hjI PwE+7iUFNk2DJ/AJaHtdoVMpvRuvZHpaSSEc4sm5HLL/pT/p/w123el+xo6tlsOLMIP/ e7/tRpMXltCPyBjQCrg6g57FY/qd3jli/jQSFxEoLluh4ndxYFc4KW2IAD0AkbSyeWIA W6LcR1FnzrWNZQPjDxOqjNM9LIXaUKjMSZ1j1kIozs8+iJ0AGkQiOzZaoEPrACFBoV4z 5EFbT1KfW5ALrtJOlPKMAmYviYMBPEKKt3WYQO5Al4sNaIUF56RmzvP4xQScE7nyhxut IiWg== X-Forwarded-Encrypted: i=1; AJvYcCVyz0+tIL3rr9e3Ev8IzvC92nthcbyGKoiNmPDdz4TxULL5GQh5lxU3o2T0+Ju2Y+jUKwJRbbfLzT6/ZLNp@postgresql.org X-Gm-Message-State: AOJu0YyHguzufTziaBHiOMonCyfrmGA+uoUGNT8JbSPji9a2khK91tZY DExipRyQsPh5I8naLT2TY/uwU9AXjLFvZ7uKMiY+3C7QYVT7TDegBhzR457/BdY5hDb67iN3G0A NGjdsv1LtL78EplAII1mNwivhjm4cmg== X-Gm-Gg: ASbGncua3SJzEO3SNSmVuXSTFAdW+oxvVUtacSs6gmStzBL12IkwtcjTQRZA6M7TZs+ uOUx8Mbrv08rxNC3URNzIQ9jcC3o/0OgwNaV56Vxs7EPRxCLiFURCORo8dqCn+0zQuDRCAhx13i 1q3XunCxkjNVl7bRCCmBHK X-Google-Smtp-Source: AGHT+IH8YluutZ8JK3e5S/bxwul7HMb5rZr/HJKak47zQM8VXYa5Kw68WKAOKiIELMXkaeF5RIqEAp1tXA13AiIlMzw= X-Received: by 2002:a05:6808:3208:b0:3fe:b27d:2681 with SMTP id 5614622812f47-4007bfc40d3mr2426295b6e.6.1744313638049; Thu, 10 Apr 2025 12:33:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:5f03:0:b0:589:13f9:e937 with HTTP; Thu, 10 Apr 2025 12:33:56 -0700 (PDT) In-Reply-To: References: <433a4165-7091-4afc-bcb9-1c1f7a5af5e0@oss.nttdata.com> From: "David G. Johnston" Date: Thu, 10 Apr 2025 12:33:56 -0700 X-Gm-Features: ATxdqUF4o0sI2bD2_RQQVWVLXIQnrENS2VppasNuXrW57y1fCKa-JtzJr0v-ur4 Message-ID: Subject: Re: tab complete for COPY populated materialized view TO To: Kirill Reshke Cc: Fujii Masao , jian he , PostgreSQL-development Content-Type: multipart/alternative; boundary="000000000000c5ebc4063271aa44" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c5ebc4063271aa44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thursday, April 10, 2025, Kirill Reshke wrote: > On Thu, 10 Apr 2025 at 20:07, Fujii Masao > wrote: > > > > > > > > On 2025/04/09 19:24, Kirill Reshke wrote: > > > On Wed, 9 Apr 2025 at 14:45, Fujii Masao > wrote: > > >> > > >> > > >> > > >> On 2025/04/09 18:25, Kirill Reshke wrote: > > >>> On Wed, 9 Apr 2025 at 13:23, jian he > wrote: > > >>>> > > >>>> hi. > > >>>> > > >>>> we allow the "COPY table TO" command to copy rows from materialize= d > > >>>> views in [1]. > > >>>> The attached patch is to add a tab complete for it. > > >>>> > > >>>> [1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=3D > 534874fac0b34535c9a5ab9257d6574f78423578 > > >>> > > >>> Hi! > > >>> Patch works good for me, but I noticed that psql COPY suggest= s > > >>> partitioned relation both with and without this patch. Maybe that's > > >>> not a big problem, if [0] will be pushed. > > >> > > >> Is the partitioned table currently tab-completed for the COPY FROM > case? > > > > > > If I'm not mistaken, yes. I double checked. > > > > > >> INSTEAD OF INSERT triggers - though maybe that's overkill? > > > > > > That's wild to me, psql tab completions feature designed to support > > > postgresql not fully, but in frequent cases. So maybe we should keep > > > it stupud. > > > > I agree that it's reasonable to exclude such rarely used objects from > > tab-completion. How about including just tables, partitioned tables, > > foreign tables, and materialized views? > > I've attached a patch for that. > > > > Regards, > > Patch is ok. However... I concur with the premise of the patch. Tab-complete is going to happen before we know whether to/from is specified so the syntax limits our smarts here. > > If we aim to support tab-completion for all valid targets of both COPY = TO > and COPY FROM, shouldn't foreign tables also be included? > > Ah.. Sorry I missed this part of your message initially. No, foreign > tables are not supported: They are supported for the From variant; valid completions need only satisfy one of to/from, not both. > > What's funny is that copying foreign tables using MV works fine > > ``` > reshke=3D# create materialized view mv as table ft; > SELECT 1 > reshke=3D# copy mv to stdout; > 228 > ``` > I don=E2=80=99t get why this is =E2=80=9Cfunny=E2=80=9D or otherwise surpri= sing. David J. --000000000000c5ebc4063271aa44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thursday, April 10, 2025, Kirill Reshke <reshkekirill@gmail.com> wrote:
On Thu, 10 Apr 2025 at 20:07, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>
>
>
> On 2025/04/09 19:24, Kirill Reshke wrote:
> > On Wed, 9 Apr 2025 at 14:45, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> >>
> >>
> >>
> >> On 2025/04/09 18:25, Kirill Reshke wrote:
> >>> On Wed, 9 Apr 2025 at 13:23, jian he <jian.universality@gmail.com> wrote: > >>>>
> >>>> hi.
> >>>>
> >>>> we allow the "COPY table TO" command to cop= y rows from materialized
> >>>> views in [1].
> >>>> The attached patch is to add a tab complete for it. > >>>>
> >>>> [1] https://git.postgresql.org/cgit/postgresql.git/commit/?id= =3D534874fac0b34535c9a5ab9257d6574f78423578
> >>>
> >>> Hi!
> >>> Patch works good for me, but I noticed that psql COPY <= ;tab> suggests
> >>> partitioned relation both with and without this patch. Ma= ybe that's
> >>> not a big problem, if [0] will be pushed.
> >>
> >> Is the partitioned table currently tab-completed for the COPY= FROM case?
> >
> > If I'm not mistaken, yes. I double checked.
> >
> >> INSTEAD OF INSERT triggers - though maybe that's overkill= ?
> >
> > That's wild to me, psql tab completions feature designed to s= upport
> > postgresql not fully, but in frequent cases. So maybe we should k= eep
> > it stupud.
>
> I agree that it's reasonable to exclude such rarely used objects f= rom
> tab-completion. How about including just tables, partitioned tables, > foreign tables, and materialized views?
> I've attached a patch for that.
>
> Regards,

Patch is ok. However...

I concur with the p= remise of the patch.=C2=A0 Tab-complete is going to happen before we know w= hether to/from is specified so the syntax limits our smarts here.


> If we aim to support tab-completion for all valid targets of both COPY= TO
and COPY FROM, shouldn't foreign tables also be included?

Ah.. Sorry I missed this part of your message initially. No, foreign
tables are not supported:

They are supporte= d for the From variant; valid completions need only satisfy one of to/from,= not both.
=C2=A0

What's funny is that copying foreign tables using MV works fine

```
reshke=3D# create materialized view mv as table ft;
SELECT 1
reshke=3D# copy mv to stdout;
228
```

I don=E2=80=99t get why this is =E2= =80=9Cfunny=E2=80=9D or otherwise surprising.

Davi= d J.

--000000000000c5ebc4063271aa44--