Horton

Thread

Commits

  1. Handle \v as a whitespace character in parsers

  1. Consider \v to the list of whitespace characters in the parser

    Michael Paquier <michael@paquier.xyz> — 2023-06-21T06:45:32Z

    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

  2. Re: Consider \v to the list of whitespace characters in the parser

    Peter Eisentraut <peter@eisentraut.org> — 2023-07-03T10:17:10Z

    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.

  3. Re: Consider \v to the list of whitespace characters in the parser

    Michael Paquier <michael@paquier.xyz> — 2023-07-04T00:00:51Z

    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

  4. Re: Consider \v to the list of whitespace characters in the parser

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-07-04T00:15:03Z

    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

  5. Re: Consider \v to the list of whitespace characters in the parser

    Michael Paquier <michael@paquier.xyz> — 2023-07-04T00:28:21Z

    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

  6. Re: Consider \v to the list of whitespace characters in the parser

    Michael Paquier <michael@paquier.xyz> — 2023-07-05T23:34:00Z

    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