Re: proposal: possibility to read dumped table's name from file
| От | Pavel Stehule |
|---|---|
| Тема | Re: proposal: possibility to read dumped table's name from file |
| Дата | |
| Msg-id | CAFj8pRDqvv6Cp7Q4X+g3e=9+zVcFSAe6w8KmxB1GDuKPgH=d6Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: proposal: possibility to read dumped table's name from file (Daniel Gustafsson <daniel@yesql.se>) |
| Ответы |
Re: proposal: possibility to read dumped table's name from file
|
| Список | pgsql-hackers |
po 12. 9. 2022 v 9:59 odesílatel Daniel Gustafsson <daniel@yesql.se> napsal:
> On 9 Sep 2022, at 11:00, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>> On Sep 9, 2022, at 5:53 PM, John Naylor <john.naylor@enterprisedb.com> wrote:
>>
>> Note that the grammar has shift-reduce conflicts.
> Looks like the last rule for Filters should not be there.
Correct, fixed in the attached.
> I do wonder whether we should be using bison/flex here, seems like using a
> sledgehammer to crack a nut.
I don't the capabilities of the tool is all that interesting compared to the
long term maintainability and readability of the source code. Personally I
think a simple Bison/Flex parser is easier to read and reason about than the
corresponding written in C.
When this work is done, then there is no reason to throw it. The parser in bison/flex does the same work and it is true, so code is more readable. Although for this case, a handy written parser was trivial too.
Regards
Pavel
--
Daniel Gustafsson https://vmware.com/
В списке pgsql-hackers по дате отправления: