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 по дате отправления:

Предыдущее
От: Andrey Borodin
Дата:
Сообщение: Re: pg_stat_statements locking
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: pg_stat_statements locking