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

From Daniel Gustafsson
Subject Re: proposal: possibility to read dumped table's name from file
Date
Msg-id 845FB45F-BA66-426F-9083-5832B589F00C@yesql.se
Whole thread Raw
In response to Re: proposal: possibility to read dumped table's name from file  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: possibility to read dumped table's name from file
Re: proposal: possibility to read dumped table's name from file
List pgsql-hackers
As noted upthread at some point, I'm not overly excited about the parser in
filter.c, for maintainability and readability reasons.  So, I've reimplemented
the parser in Flex/Bison in the attached patch, which IMHO provides a clear(er)
picture of the grammar and is more per project standards.  This version of the
patch is your latest version with just the parser replaced (at a reduction in
size as a side benefit).

All features supported in your latest patch version are present, and it passes
all the tests added by this patch.  It's been an undisclosed amount of years
since I wrote a Bison parser (well, yacc really) from scratch so I don't rule
out having made silly mistakes.  I would very much appreciate review from those
more well versed in this area.

One thing this patchversion currently lacks is refined error messaging, but if
we feel that this approach is a viable path then that can be tweaked.  The
function which starts the parser can also be refactored to be shared across
pg_dump, pg_dumpall and pg_restore but I've kept it simple for now.

Thoughts?  It would be nice to get this patch across the finishline during this
commitfest.

--
Daniel Gustafsson        https://vmware.com/


Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: START_REPLICATION SLOT causing a crash in an assert build
Next
From: Vitaly Burovoy
Date:
Subject: Doc fix and adjustment for MERGE command