Re: proposal: possibility to read dumped table's name from file - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: proposal: possibility to read dumped table's name from file
Date
Msg-id A9A76268-A5F7-4922-888E-E813CC9A9493@dunslane.net
Whole thread Raw
In response to Re: proposal: possibility to read dumped table's name from file  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: proposal: possibility to read dumped table's name from file
List pgsql-hackers



> On Sep 9, 2022, at 5:53 PM, John Naylor <john.naylor@enterprisedb.com> wrote:
>
> On Thu, Sep 8, 2022 at 7:32 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>> [v3]
>
> Note that the grammar has shift-reduce conflicts. If you run a fairly
> recent Bison, you can show them like this:
>
> bison -Wno-deprecated -Wcounterexamples -d -o filterparse.c filterparse.y
>
> filterparse.y: warning: 2 shift/reduce conflicts [-Wconflicts-sr]
> filterparse.y: warning: shift/reduce conflict on token C_INCLUDE
> [-Wcounterexamples]
>  Example: • C_INCLUDE include_object pattern
>  Shift derivation
>    Filters
>    ↳ 3: Filter
>         ↳ 4: • C_INCLUDE include_object pattern
>  Reduce derivation
>    Filters
>    ↳ 2: Filters  Filter
>         ↳ 1: ε • ↳ 4: C_INCLUDE include_object pattern
> filterparse.y: warning: shift/reduce conflict on token C_EXCLUDE
> [-Wcounterexamples]
>  Example: • C_EXCLUDE exclude_object pattern
>  Shift derivation
>    Filters
>    ↳ 3: Filter
>         ↳ 5: • C_EXCLUDE exclude_object pattern
>  Reduce derivation
>    Filters
>    ↳ 2: Filters  Filter
>         ↳ 1: ε • ↳ 5: C_EXCLUDE exclude_object pattern
>


Looks like the last rule for Filters should not be there. I do wonder whether we should be using bison/flex here, seems
likeusing a sledgehammer to crack a nut. 

Cheers

Andrew


pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Possible crash on standby
Next
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Perform streaming logical transactions by background workers and parallel apply