Re: Bug in pg_dump --filter? - Invalid object types can be misinterpreted as valid - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Bug in pg_dump --filter? - Invalid object types can be misinterpreted as valid
Date
Msg-id CAHGQGwE4V68wh9CZbTbrGxjdguMsyA4pOO_0_LYLKRHVPDADuw@mail.gmail.com
Whole thread Raw
In response to Re: Bug in pg_dump --filter? - Invalid object types can be misinterpreted as valid  (Xuneng Zhou <xunengzhou@gmail.com>)
Responses Re: Bug in pg_dump --filter? - Invalid object types can be misinterpreted as valid
List pgsql-hackers
On Sun, Aug 3, 2025 at 3:03 PM Xuneng Zhou <xunengzhou@gmail.com> wrote:
> After testing, the patch LGTM. I noticed two very small possible nits:

Thanks for the review!


> 1) Comment wording
>
> The loop now calls isspace((unsigned char)*ptr), so a token ends at
> any whitespace, not just at ASCII space (0x20). Could we revise the
> comment—from
> “strings of non-space characters bounded by space characters”
> to something like
> “strings of non-space characters bounded by whitespace”
> —to match the behavior?

I agree with the change. But the phrase "strings of non-space characters
bounded by whitespace" is a bit redundant, and "strings of non-whitespace
characters" is sufficient, isn't it? So I used that wording in the updated
patch I've attached.


> 2) Variable name
>
> const char *keyword = filter_get_token(&str, &size);
> keyword = filter_get_token(&str, &size);
>
> After the patch, filter_get_token() no longer returns a keyword
> (letters-only identifier); it now returns any non-whitespace token.
> Renaming the variable from keyword to token (or similar) might make
> the intent clearer..

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?

Regards,

--
Fujii Masao

Attachment

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Improving and extending int128.h to more of numeric.c
Next
From: Fabrice Chapuis
Date:
Subject: Re: set role issue