Re: PATCH: pg_dump to support "on conflict do update"
От | Tom Lane |
---|---|
Тема | Re: PATCH: pg_dump to support "on conflict do update" |
Дата | |
Msg-id | 2645193.1746456936@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PATCH: pg_dump to support "on conflict do update" (Laurenz Albe <laurenz.albe@cybertec.at>) |
Список | pgsql-hackers |
Laurenz Albe <laurenz.albe@cybertec.at> writes: > On Sat, 2025-05-03 at 22:47 -0700, Tanin Na Nakorn wrote: >> Here's the patch (against the latest master) that will make pg_dump support "on conflict do update" . >> >> There are 3 caveats: >> >> 1. The "on conflict do update" would apply to every table. In my opinion, this is fine. > I don't think that is fine. I think it would make the feature unusable for most cases. > At the very least, there would have to be a way to specify which tables are affected. Yeah. I kind of feel that this entire idea is misguided. pg_dump is not an ETL tool, and bolting ETL-ish features onto it one at a time seems destined to end in a mess. But it's particularly awful that the proposed switch design would apply to all tables. That pretty much makes it useless except in a dump that selects only one table. It's also useless except in a --data-only dump, since if we create the target table then we know perfectly well that it's empty to start with. So at this point you barely need pg_dump at all, as opposed to some other tool that does a light syntactic transformation on the result of COPY. I think it could be interesting to try to build something that *is* an ETL tool and is meant for cases like partial data loads. But pg_dump is serving more than enough masters already. Let's not add this to its plate. regards, tom lane
В списке pgsql-hackers по дате отправления: