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

Hi,

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:

+Patterns:
+ /* EMPTY */
+ | Patterns Pattern
+ | 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?