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 | CAFj8pRDcdAxSRxqwZ-Aywt-SvdNupOY6rrBUevND=nXaDDtvVg@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 |
>
> Initially not, but now, when I am thinking about it, I don't think so Bison helps. The syntax of the filter file is nicely linear. Now, the code of the parser is a little bit larger than minimalistic, but it is due to nicer error's messages. The raw implementation in Bison raised just "syntax error" and positions. I did code refactoring, and now the scanning, parsing and processing are divided into separated routines. Parsing related code has 90 lines. In this case, I don't think using a parser grammar file can carry any benefit. grammar is more readable, sure, but we need to include bison, we need to handle errors, and if we want to raise more helpful errors than just "syntax error", then the code will be longer.
I'm not so concerned by code size, but rather parsing of quotations etc and
being able to reason about it's correctness. IMHO that's easier done by
reading a defined grammar than parsing a handwritten parser.
In this case the complex part is not a parser, but the scanner is complex and writing this in flex is not too easy. I wrote so the grammar file can be more readable, but the usual error from Bison is "syntax error" and position, so it does not win from the user perspective. When a parser is not linear, then a generated parser can help a lot, but using it at this moment is premature.
Will do a closer review on the patch shortly.
--
Daniel Gustafsson https://vmware.com/
В списке pgsql-hackers по дате отправления: