Re: proposal: possibility to read dumped table's name from file

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Erik Rijkers <er(at)xs4all(dot)nl>, 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
Date: 2022-09-08 11:44:30
Message-ID: 20220908114430.zp7fgk3c6gmjnt7m@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On Thu, Sep 08, 2022 at 01:38:42PM +0200, Daniel Gustafsson wrote:
> > 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
> >> commitfest.
> >
> > > [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.

I only had a quick look at the parser, and one thing that strikes me is:

+ /* EMPTY */
+ | Patterns Pattern
+ | Pattern
+ ;
+ C_INCLUDE include_object pattern { include_item(priv, $2, $3); }

It seems confusing to mix Pattern(s) (the rules) and pattern (the token).
Maybe instead using Include(s) or Item(s) on the bison side, and/or
name_pattern on the lexer side?

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2022-09-08 11:46:53 Re: Switching XLog source from archive to streaming when primary available
Previous Message Daniel Gustafsson 2022-09-08 11:38:42 Re: proposal: possibility to read dumped table's name from file