Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
737f1cd4
G
Gpdb
项目概览
Greenplum
/
Gpdb
通知
7
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
Gpdb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
737f1cd4
编写于
2月 19, 2004
作者:
T
Tom Lane
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Cosmetic changes (mostly whitespace) to make it easier to diff the
backend lexer against psql's.
上级
2e3d5f11
变更
1
显示空白变更内容
内联
并排
Showing
1 changed file
with
58 addition
and
51 deletion
+58
-51
src/backend/parser/scan.l
src/backend/parser/scan.l
+58
-51
未找到文件。
src/backend/parser/scan.l
浏览文件 @
737f1cd4
...
...
@@ -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.11
2 2003/11/29 19:51:52 pgsq
l Exp $
* $PostgreSQL: pgsql/src/backend/parser/scan.l,v 1.11
3 2004/02/19 19:11:30 tg
l 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];
}
%%
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录