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

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>, jian he <jian.universality@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>
Date: 2025-03-29T18:56:03Z
Lists: pgsql-hackers
On 2025-03-29 Sa 12:17 PM, David G. Johnston wrote:
> On Sat, Mar 29, 2025 at 9:06 AM Andrew Dunstan <andrew@dunslane.net> 
> wrote:
>
>
>     On 2025-03-29 Sa 10:40 AM, David G. Johnston wrote:
>>     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.
>
>
>     *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.
>
>
>
>
> "copy {subquery} to" is a general-purpose exporter that makes use of 
> those additional features.  Sure, they also work for the narrowed case 
> of "copy {relation/table} to" but I make my claim on the very fact 
> that {relation} cannot be stuff like foreign tables or partitioned 
> tables, which pg_dump has no need to target.
>
>


I don't believe that the premise supports the conclusion.


cheers


andrew

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

Commits

  1. Allow "COPY table TO" command to copy rows from materialized views.