Re: in BeginCopyTo make materialized view using COPY TO instead of COPY (query).
От | Andrew Dunstan |
---|---|
Тема | Re: in BeginCopyTo make materialized view using COPY TO instead of COPY (query). |
Дата | |
Msg-id | e38cbf42-0f8e-4c3b-8c77-70c83116fdb2@dunslane.net обсуждение исходный текст |
Ответ на | Re: in BeginCopyTo make materialized view using COPY TO instead of COPY (query). ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: in BeginCopyTo make materialized view using COPY TO instead of COPY (query).
|
Список | pgsql-hackers |
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.
cheers
andew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: