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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Peter Eisentraut <peter@eisentraut.org>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, Evan Jones <evan.jones@datadoghq.com>
Date: 2023-07-04T00:15:03Z
Lists: pgsql-hackers
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



Commits

  1. Handle \v as a whitespace character in parsers