|From:||Daniel Gustafsson <daniel(at)yesql(dot)se>|
|To:||Erik Rijkers <er(at)xs4all(dot)nl>|
|Cc:||Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Surafel Temesgen <surafel3000(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: proposal: possibility to read dumped table's name from file|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> On 8 Sep 2022, at 12:00, Erik Rijkers <er(at)xs4all(dot)nl> wrote:
> Op 07-09-2022 om 21:45 schreef Daniel Gustafsson:
>> One thing this patchversion currently lacks is refined error messaging, but if
>> we feel that this approach is a viable path then that can be tweaked. The
>> function which starts the parser can also be refactored to be shared across
>> pg_dump, pg_dumpall and pg_restore but I've kept it simple for now.
>> Thoughts? It would be nice to get this patch across the finishline during this
> > [0001-Add-include-exclude-filtering-via-file-in-pg_dump.patch]
> This seems to dump & restore well (as Pavels patch does).
Thanks for looking!
> I did notice one peculiarity (in your patch) where for each table a few spaces are omitted by pg_dump.
Right, I had that on my TODO to fix before submitting but clearly forgot. It
boils down to consuming the space between commands and object types and object
patterns. The attached v2 fixes that.
Daniel Gustafsson https://vmware.com/
|Next Message||Julien Rouhaud||2022-09-08 11:44:30||Re: proposal: possibility to read dumped table's name from file|
|Previous Message||Peter Eisentraut||2022-09-08 11:36:07||why can't a table be part of the same publication as its schema|