Обсуждение: Consider \v to the list of whitespace characters in the parser
Hi all, (Adding Evan in CC as he has reported the original issue with hstore.) $subject has showed up as a subject for discussion when looking at the set of whitespace characters that we use in the parsers: https://www.postgresql.org/message-id/CA+HWA9bTRDf52DHyU+JOoqEALgRGRo5uHUYTFuduoj3cBfer+Q@mail.gmail.com On HEAD, these are \t, \n, \r and \f which is consistent with the list that we use in scanner_isspace(). This has quite some history, first in 9ae2661 that dealt with an old issue with BSD's isspace where whitespaces may not be detected correctly. hstore has been recently changed to fix the same problem with d522b05, still depending on scanner_isspace() for the job makes the handling of \v kind of strange. That's not the end of the story. There is an inconsistency with the way array values are handled for the same problem, where 95cacd1 added handling for \v in the list of what's considered a whitespace. Attached is a patch to bring a bit more consistency across the board, by adding \v to the set of characters that are considered as whitespace by the parser. Here are a few things that I have noticed in passing: - JSON should not escape \v, as defined in RFC 7159. - syncrep_scanner.l already considered \v as a whitespace. Its neighbor repl_scanner.l did not do that. - There are a few more copies that would need a refresh of what is considered as a whitespace in their respective lex scanners: psqlscan.l, psqlscanslash.l, cubescan.l, segscan.l, ECPG's pgc.l. One thing I was wondering: has the SQL specification anything specific about the way vertical tabs should be parsed? Thoughts and comments are welcome. Thanks, -- Michael
Вложения
On 21.06.23 08:45, Michael Paquier wrote: > One thing I was wondering: has the SQL specification anything specific > about the way vertical tabs should be parsed? SQL has "whitespace", which includes any Unicode character with the White_Space property (which includes \v), and <newline>, which is implementation-defined. So nothing there speaks against treating \v as a (white)space character in the SQL scanner. In scan.l, you might want to ponder horiz_space: Even though \v is clearly not "horizontal space", horiz_space already includes \f, which is also not horizontal IMO. I think horiz_space is really all space characters except newline characters. Maybe this should be rephrased.
On Mon, Jul 03, 2023 at 12:17:10PM +0200, Peter Eisentraut wrote: > SQL has "whitespace", which includes any Unicode character with the > White_Space property (which includes \v), and <newline>, which is > implementation-defined. > > So nothing there speaks against treating \v as a (white)space character in > the SQL scanner. Okay, thanks for confirming. > In scan.l, you might want to ponder horiz_space: Even though \v is clearly > not "horizontal space", horiz_space already includes \f, which is also not > horizontal IMO. I think horiz_space is really all space characters except > newline characters. Maybe this should be rephrased. And a few lines above, there is a comment from 2000 (3cfdd8f) pondering if \f should be handled as a newline, which is kind of incorrect anyway? FWIW, I agree that horiz_space is confusing in this context because it does not completely reflect the reality, and \v is not that so adding it to the existing list felt wrong to me. Form feed is also not a newline, from what I understand.. From what the parser tells, there are two things we want to track to handle comments: - All space characters, which would be \t\n\r\f\v. - All space characters that are not newlines, \t\f\v. I don't really have a better idea this morning than using the following terms in the parser, changing the surroundings with similar terms: -space [ \t\n\r\f] -horiz_space [ \t\f] +space [ \t\n\r\f\v] +non_newline_space [ \t\f\v] Perhaps somebody has a better idea of split? -- Michael
Вложения
Michael Paquier <michael@paquier.xyz> writes: > On Mon, Jul 03, 2023 at 12:17:10PM +0200, Peter Eisentraut wrote: >> In scan.l, you might want to ponder horiz_space: Even though \v is clearly >> not "horizontal space", horiz_space already includes \f, which is also not >> horizontal IMO. I think horiz_space is really all space characters except >> newline characters. Maybe this should be rephrased. > And a few lines above, there is a comment from 2000 (3cfdd8f) > pondering if \f should be handled as a newline, which is kind of > incorrect anyway? It looks to me like there are two places where these distinctions actually matter: 1. Which characters terminate a "--" comment. Currently that's only [\n\r] (see {non_newline}). 2. Which characters satisfy the SQL spec's requirement that there be a newline in the whitespace separating string literals that are to be concatenated. Currently, that's also only [\n\r]. Assuming we don't want to change either of these distinctions, the v2 patch looks about right to me. regards, tom lane
On Mon, Jul 03, 2023 at 08:15:03PM -0400, Tom Lane wrote: > Assuming we don't want to change either of these distinctions, > the v2 patch looks about right to me. Yeah, thanks. Peter, what's your take? -- Michael
Вложения
On Tue, Jul 04, 2023 at 09:28:21AM +0900, Michael Paquier wrote: > Yeah, thanks. I have looked again at that this morning, and did not notice any missing spots, so applied.. Let's see how it goes. -- Michael