Re: in BeginCopyTo make materialized view using COPY TO instead of COPY (query).

On 2025-03-29 Sa 10:40 AM, David G. Johnston wrote:
> On Saturday, March 29, 2025, Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:
>
> On Sat, 29 Mar 2025 at 09:47, jian he
> <jian(dot)universality(at)gmail(dot)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.

*ahem*

What is your evidence for that proposition? If this were true we would
not support CSV mode, which pg_dump does not use. It might have
limitations, but its use goes far beyond just pg_dump, both in theory
and practice.

cheers

andew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com