I am sending version with handy written parser and meson support
po 3. 10. 2022 v 6:34 odesílatel Julien Rouhaud <rjuju123@gmail.com> napsal:
Hi,
> You started rewriting it, but you didn't finish it. > > Unfortunately, there is not a clean opinion on using bison's parser for > this purpose. I understand that the complexity of this language is too low, > so the benefit of using bison's gramatic is low too. Personally, I have not > any problem using bison for this purpose. For this case, I think we compare > two similarly long ways, but unfortunately, customers that have a problem > with long command lines still have this problem. > > Can we go forward? Daniel is strongly against handwritten parser. Is there > somebody strongly against bison's based parser? There is not any other way.
I don't have a strong opinion either, but it seems that 2 people argued against a bison parser (vs only 1 arguing for) and the fact that the current habit is to rely on hand written parsers for simple cases (e.g. jsonapi.c / pg_parse_json()), it seems that we should go back to Pavel's original parser.
I only had a quick look but it indeed seems trivial, it just maybe need a bit of refactoring to avoid some code duplication (getFiltersFromFile is duplicated, and getDatabaseExcludeFiltersFromFile could be removed if getFiltersFromFile knew about the 2 patterns).
I checked this code again, and I don't think some refactoring is easy. getFiltersFromFile is not duplicated. It is just probably badly named.
These routines are used from pg_dump, pg_dumpall and pg_restore. There are significant differences in supported objects and in types used for returned lists (dumpOptions, SimpleStringList, and RestoreOptions). If I have one routine, then I need to implement some mechanism for specification of supported objects, and a special type that can be used as a proxy between caller and parser to hold lists of parsed values. To be names less confusing I renamed them to read_dump_filters, read_dumpall_filters and read_restore_filters
