database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-08 07:21:33 +03:00
Code

Cosmetic changes (mostly whitespace) to make it easier to diff the

Browse Source 
backend lexer against psql's.
This commit is contained in:
Tom Lane 2004-02-19 19:11:30 +00:00
parent 2e3d5f1160
commit 737f1cd44b
1 changed files with 58 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

109
src/backend/parser/scan.l
View File

@ -4,12 +4,13 @@
* scan.l
* lexical scanner for PostgreSQL
*
* XXX The rules in this file must be kept in sync with psql's lexer!!!
*
* Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/parser/scan.l,v 1.112 2003/11/29 19:51:52 pgsql Exp $
* $PostgreSQL: pgsql/src/backend/parser/scan.l,v 1.113 2004/02/19 19:11:30 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -29,9 +30,6 @@
#include "utils/builtins.h"
#include "mb/pg_wchar.h"
/* No reason to constrain amount of data slurped */
#define YY_READ_BUF_SIZE 16777216
/* Avoid exit() on fatal scanner errors (a bit ugly -- see yy_fatal_error) */
#define fprintf(file, fmt, msg) ereport(ERROR, (errmsg_internal("%s", msg)))
@ -103,6 +101,41 @@ unsigned char unescape_single_char(unsigned char c);
%x xh
%x xq
/*
* In order to make the world safe for Windows and Mac clients as well as
* Unix ones, we accept either \n or \r as a newline. A DOS-style \r\n
* sequence will be seen as two successive newlines, but that doesn't cause
* any problems. Comments that start with -- and extend to the next
* newline are treated as equivalent to a single whitespace character.
*
* NOTE a fine point: if there is no newline following --, we will absorb
* everything to the end of the input as a comment. This is correct. Older
* versions of Postgres failed to recognize -- as a comment if the input
* did not end with a newline.
*
* XXX perhaps \f (formfeed) should be treated as a newline as well?
*/
space [ \t\n\r\f]
horiz_space [ \t\f]
newline [\n\r]
non_newline [^\n\r]
comment ("--"{non_newline}*)
whitespace ({space}+|{comment})
/*
* SQL requires at least one newline in the whitespace separating
* string literals that are to be concatenated. Silly, but who are we
* to argue? Note that {whitespace_with_newline} should not have * after
* it, whereas {whitespace} should generally have a * after it...
*/
special_whitespace ({space}+|{comment}{newline})
horiz_whitespace ({horiz_space}|{comment})
whitespace_with_newline ({horiz_whitespace}*{newline}{special_whitespace}*)
/* Bit string
* It is tempting to scan the string for only those characters
* which are allowed. However, this leads to silently swallowed
@ -205,41 +238,6 @@ real ((({digit}*\.{digit}+)|({digit}+\.{digit}*)|({digit}+))([Ee][-+]?{digit}+
param \${integer}
/*
* In order to make the world safe for Windows and Mac clients as well as
* Unix ones, we accept either \n or \r as a newline. A DOS-style \r\n
* sequence will be seen as two successive newlines, but that doesn't cause
* any problems. Comments that start with -- and extend to the next
* newline are treated as equivalent to a single whitespace character.
*
* NOTE a fine point: if there is no newline following --, we will absorb
* everything to the end of the input as a comment. This is correct. Older
* versions of Postgres failed to recognize -- as a comment if the input
* did not end with a newline.
*
* XXX perhaps \f (formfeed) should be treated as a newline as well?
*/
space [ \t\n\r\f]
horiz_space [ \t\f]
newline [\n\r]
non_newline [^\n\r]
comment ("--"{non_newline}*)
whitespace ({space}+|{comment})
/*
* SQL requires at least one newline in the whitespace separating
* string literals that are to be concatenated. Silly, but who are we
* to argue? Note that {whitespace_with_newline} should not have * after
* it, whereas {whitespace} should generally have a * after it...
*/
special_whitespace ({space}+|{comment}{newline})
horiz_whitespace ({horiz_space}|{comment})
whitespace_with_newline ({horiz_whitespace}*{newline}{special_whitespace}*)
other .
/*
@ -261,7 +259,9 @@ other .
token_start = NULL;
%}
{whitespace} { /* ignore */ }
{whitespace} {
/* ignore */
}
{xcstart} {
token_start = yytext;
@ -288,9 +288,13 @@ other .
xcdepth--;
}
<xc>{xcinside} { /* ignore */ }
<xc>{xcinside} {
/* ignore */
}
<xc>{op_chars} { /* ignore */ }
<xc>{op_chars} {
/* ignore */
}
<xc><<EOF>> { yyerror("unterminated /* comment"); }
@ -319,9 +323,8 @@ other .
<xb>{xbcat} {
/* ignore */
}
<xb><<EOF>> {
yyerror("unterminated bit string literal");
}
<xb><<EOF>> { yyerror("unterminated bit string literal"); }
{xhstart} {
/* Hexadecimal bit type.
* At some point we should simply pass the string
@ -358,7 +361,6 @@ other .
return keyword->value;
}
{xqstart} {
token_start = yytext;
BEGIN(xq);
@ -387,7 +389,6 @@ other .
}
<xq><<EOF>> { yyerror("unterminated quoted string"); }
{xdstart} {
token_start = yytext;
BEGIN(xd);
@ -421,9 +422,13 @@ other .
}
<xd><<EOF>> { yyerror("unterminated quoted identifier"); }
{typecast} { return TYPECAST; }
{typecast} {
return TYPECAST;
}
{self} { return yytext[0]; }
{self} {
return yytext[0];
}
{operator} {
/*
@ -571,7 +576,9 @@ other .
return IDENT;
}
{other} { return yytext[0]; }
{other} {
return yytext[0];
}
%%