MIME-Version: 1.0
In-Reply-To: 
 <CALdSSPi3Gb=fi0ZCoJhAp3HQYKJmiCShcX4xMcUBSL0s5byBXQ@mail.gmail.com>
References: 
 <CACJufxHVxnyRYy67hiPePNCPwVBMzhTQ6FaL9_Te5On9udG=yg@mail.gmail.com>
 <Z2Sz7LU1akdewn5U@paquier.xyz>
 <CACJufxGvy6QNMwZ5xd=L31F+4Rr6aXCASeMFyLZS+TVssK5+vA@mail.gmail.com>
 <CACJufxGZgh4oNV_8TqBwRoL+WFB2n3EqN97aMcuEmjuG+qm0qw@mail.gmail.com>
 <CACJufxHnyH4Zv+RtOABn8-1PjxkKch9R58dGhr+hCnV0LmNxSQ@mail.gmail.com>
 <CALdSSPgsgC_CGDjTyzu=1FAbuavTRsGFDnnm7ufGuWcd29QUHQ@mail.gmail.com>
 <CACJufxE35HxSMqG6su0txZwOLpbnBsDBav5eigxt6L8Nk8bJwQ@mail.gmail.com>
 <CALdSSPi3Gb=fi0ZCoJhAp3HQYKJmiCShcX4xMcUBSL0s5byBXQ@mail.gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Sat, 29 Mar 2025 07:40:55 -0700
Message-ID: 
 <CAKFQuwbs61rxxCUVhECLSq4Xrz9s54dD2TzhX58d7+6WcC8dpA@mail.gmail.com>
Subject: Re: in BeginCopyTo make materialized view using COPY TO instead of
 COPY (query).
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: jian he <jian.universality@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Tom Lane <tgl@sss.pgh.pa.us>,
	Michael Paquier <michael@paquier.xyz>
Content-Type: multipart/alternative; boundary="000000000000c1a81d06317c2cff"
Archived-At: 
 <https://www.postgresql.org/message-id/CAKFQuwbs61rxxCUVhECLSq4Xrz9s54dD2TzhX58d7%2B6WcC8dpA%40mail.gmail.com>
Precedence: bulk

--000000000000c1a81d06317c2cff
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Saturday, March 29, 2025, Kirill Reshke <reshkekirill@gmail.com> wrote:

> On Sat, 29 Mar 2025 at 09:47, jian he <jian.universality@gmail.com> wrote=
:
> >
> > will use {table_beginscan, table_scan_getnextslot, table_endscan}
> > to output the data.
> > but views don't have storage, table_beginscan mechanism won't work.
> >
> > so i don't think this is possible for view.
>
> Well... So you are saying that let us have inconsistent features
> because of how things are implemented in core... I don't sure I'm
> buying that, but whatever, let's hear some other voices from the
> community. My argument is that while we are working on it, perhaps we
> should revise certain implementation specifics along the way. However,
> this is merely my opinion on the matter.
>

 At present copy {table} to only exists to support pg_dump.  It is not
marketed as a general purpose export facility.  While copy {relation} from
is a general purpose importer.  Do we want to turn copy to into a general
purpose exporter and start accepting patches to export foreign tables, deal
with partitioned tables, views of both kinds?  Given we already accept
things in copy from that copy to cannot produce the symmetry argument seems
flawed.

I=E2=80=99m on board with making copy {relation} to a general purpose expor=
t
facility and allowing for incremental implementations as people wish to
spend time developing them.  Consistency should not prevent progress here.

On the topic of copy {matview} from, why not permit it?  In particular,
with dump/restore we could dump the materialized view and restore it, which
seems like a win in terms of time spent restoring.  That wouldn=E2=80=99t b=
e this
patch.

David J.

--000000000000c1a81d06317c2cff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Saturday, March 29, 2025, Kirill Reshke &lt;<a href=3D"mailto:reshkekiri=
ll@gmail.com">reshkekirill@gmail.com</a>&gt; wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">On Sat, 29 Mar 2025 at 09:47, jian he &lt;<a href=3D"mailto:jian=
.universality@gmail.com">jian.universality@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; will use {table_beginscan, table_scan_getnextslot, table_endscan}<br>
&gt; to output the data.<br>
&gt; but views don&#39;t have storage, table_beginscan mechanism won&#39;t =
work.<br>
&gt;<br>
&gt; so i don&#39;t think this is possible for view.<br>
<br>
Well... So you are saying that let us have inconsistent features<br>
because of how things are implemented in core... I don&#39;t sure I&#39;m<b=
r>
buying that, but whatever, let&#39;s hear some other voices from the<br>
community. My argument is that while we are working on it, perhaps we<br>
should revise certain implementation specifics along the way. However,<br>
this is merely my opinion on the matter.<br>
</blockquote><div><br></div><div>=C2=A0At present copy {table} to only exis=
ts to support pg_dump.=C2=A0 It is not marketed as a general purpose export=
 facility.=C2=A0 While copy {relation} from is a general purpose importer.=
=C2=A0 Do we want to turn copy to into a general purpose exporter and start=
 accepting patches to export foreign tables, deal with partitioned tables, =
views of both kinds?=C2=A0 Given we already accept things in copy from that=
 copy to cannot produce the symmetry argument seems flawed.</div><div><br><=
/div><div>I=E2=80=99m on board with making copy {relation} to a general pur=
pose export facility and allowing for incremental implementations as people=
 wish to spend time developing them.=C2=A0 Consistency should not prevent p=
rogress here.</div><div><br></div><div>On the topic of copy {matview} from,=
 why not permit it?=C2=A0 In particular, with dump/restore we could dump th=
e materialized view and restore it, which seems like a win in terms of time=
 spent restoring.=C2=A0 That wouldn=E2=80=99t be this patch.</div><div><br>=
</div><div>David J.</div><div><br></div>

--000000000000c1a81d06317c2cff--