Re: Bug in pg_dump --filter? - Invalid object types can be misinterpreted as valid
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Xuneng Zhou <xunengzhou@gmail.com>, srinath2133@gmail.com, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-06T04:49:32Z
Lists: pgsql-hackers
Attachments
- v3-0001-pg_dump-Fix-incorrect-parsing-of-object-types-in-.patch (application/octet-stream) patch v3-0001
On Tue, Aug 5, 2025 at 4:52 PM Daniel Gustafsson <daniel@yesql.se> wrote: > > > On 4 Aug 2025, at 17:18, Fujii Masao <masao.fujii@gmail.com> wrote: > > I missed this thread while being on vacation, thanks for finding and fixing > this! > > > This also got me thinking, if we simply define keywords as strings of > > non-whitespace characters, maybe we don't need to change the term "keyword" > > to "token" at all. I've updated the patch with that in mind. Thoughts? > > Agreed, this should work fine, and it aligns the code somwhat with read_pattern > which is a good thing. > > + * in line buffer. Returns NULL when the buffer is empty or no keyword exists. > Since "is empty" could be interpreted as being a null pointer, maybe we should > add a if (!*line) check (or an Assert) before we dereference the passed in > buffer? Thanks for the review! I've added Assert(*line != NULL) at the start of filter_get_keyword(). Updated patch attached. Regards, -- Fujii Masao
Commits
-
pg_dump: Fix incorrect parsing of object types in pg_dump --filter.
- 7dafc4a413f4 17.6 landed
- e3764229e6bd 18.0 landed
- 85ccd7e30a6d 19 (unreleased) landed