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

> On 8 Sep 2022, at 13:44, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> 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:

>>> 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,

Thanks for looking!

> .. 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?

That makes a lot of sense, I renamed the rules in the parser but kept them in
the lexer since that seemed like the clearest scheme.

Also in the attached is a small refactoring to share parser init between
pg_dump and pg_restore (pg_dumpall shares little with these so not there for
now), buffer resize overflow calculation and some error message tweaking.

--
Daniel Gustafsson https://vmware.com/