From: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
---|---|
To: | Kirk Wolak <wolakk(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Nikolay Samokhvalov <nik(at)postgres(dot)ai>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Pavlo Golub <Pavlo(dot)Golub(at)cybertec(dot)at> |
Subject: | Re: PoC: pg_dump --filter-data <file> (like Oracle Where Clause on RMAN for specific tables) |
Date: | 2025-08-15 17:25:02 |
Message-ID: | CAKAnmmLYwUw0Kc4E-aBDeYNU=S+RxRx+CTXgBR6dvERAcUvUYQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I've seen this idea pop up over the years, and it's still a good one.
Rather than invent new flags, I think a better approach would be to
convince pg_dump to dump a view, such that table foo has a view fooslice to
limit / filter the output. Then we can simply do:
pg_dump -t foo=view:fooslice
and under the hood pg_dump would do
COPY (SELECT * FROM fooslice) TO ...
rather than
COPY foo TO ...
While we could make the view mapping into a separate filtering file as you
suggest, that's more complexity and also a little more dangerous in an
action-at-a-distance way, so I'd rather have people be very specific in the
mapping on the command line.
I could swear I made a POC years ago for something like this, but it's long
gone. If I get some time, I'll give it a fresh attempt.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2025-08-15 17:39:52 | Re: Remove Instruction Synchronization Barrier in spin_delay() for ARM64 architecture |
Previous Message | Andres Freund | 2025-08-15 17:22:58 | Re: index prefetching |