4
4
* scan.l
5
5
* lexical scanner for PostgreSQL
6
6
*
7
+ * XXX The rules in this file must be kept in sync with psql's lexer!!!
8
+ *
7
9
* Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group
8
10
* Portions Copyright (c) 1994, Regents of the University of California
9
11
*
10
- *
11
12
* IDENTIFICATION
12
- * $PostgreSQL: pgsql/src/backend/parser/scan.l,v 1.112 2003/11/29 19:51:52 pgsql Exp $
13
+ * $PostgreSQL: pgsql/src/backend/parser/scan.l,v 1.113 2004/02/19 19:11:30 tgl Exp $
13
14
*
14
15
*-------------------------------------------------------------------------
15
16
*/
29
30
#include " utils/builtins.h"
30
31
#include " mb/pg_wchar.h"
31
32
32
- /* No reason to constrain amount of data slurped*/
33
- #define YY_READ_BUF_SIZE 16777216
34
-
35
33
/* Avoid exit() on fatal scanner errors (a bit ugly -- see yy_fatal_error)*/
36
34
#define fprintf (file, fmt, msg ) ereport(ERROR, (errmsg_internal(" %s" , msg)))
37
35
@@ -103,6 +101,41 @@ unsigned char unescape_single_char(unsigned char c);
103
101
%x xh
104
102
%x xq
105
103
104
+ /*
105
+ * In order to make the world safe for Windows and Mac clients as well as
106
+ * Unix ones, we accept either \n or \r as a newline. A DOS-style \r\n
107
+ * sequence will be seen as two successive newlines, but that doesn't cause
108
+ * any problems. Comments that start with -- and extend to the next
109
+ * newline are treated as equivalent to a single whitespace character.
110
+ *
111
+ * NOTE a fine point: if there is no newline following --, we will absorb
112
+ * everything to the end of the input as a comment. This is correct. Older
113
+ * versions of Postgres failed to recognize -- as a comment if the input
114
+ * did not end with a newline.
115
+ *
116
+ * XXX perhaps \f (formfeed) should be treated as a newline as well?
117
+ */
118
+
119
+ space [\t\n\r\f ]
120
+ horiz_space [\t\f ]
121
+ newline [\n\r ]
122
+ non_newline [^ \n\r ]
123
+
124
+ comment (" --" {non_newline }* )
125
+
126
+ whitespace ({space }+ | {comment })
127
+
128
+ /*
129
+ * SQL requires at least one newline in the whitespace separating
130
+ * string literals that are to be concatenated. Silly, but who are we
131
+ * to argue? Note that {whitespace_with_newline} should not have * after
132
+ * it, whereas {whitespace} should generally have a * after it...
133
+ */
134
+
135
+ special_whitespace ({space }+ | {comment }{newline })
136
+ horiz_whitespace ({horiz_space }| {comment })
137
+ whitespace_with_newline ({horiz_whitespace }* {newline }{special_whitespace }* )
138
+
106
139
/* Bit string
107
140
* It is tempting to scan the string for only those characters
108
141
* which are allowed. However, this leads to silently swallowed
@@ -205,41 +238,6 @@ real((({digit}*\.{digit}+)|({digit}+\.{digit}*)|({digit}+))([Ee][-+]?{digit}+
205
238
206
239
param \$ {integer }
207
240
208
- /*
209
- * In order to make the world safe for Windows and Mac clients as well as
210
- * Unix ones, we accept either \n or \r as a newline. A DOS-style \r\n
211
- * sequence will be seen as two successive newlines, but that doesn't cause
212
- * any problems. Comments that start with -- and extend to the next
213
- * newline are treated as equivalent to a single whitespace character.
214
- *
215
- * NOTE a fine point: if there is no newline following --, we will absorb
216
- * everything to the end of the input as a comment. This is correct. Older
217
- * versions of Postgres failed to recognize -- as a comment if the input
218
- * did not end with a newline.
219
- *
220
- * XXX perhaps \f (formfeed) should be treated as a newline as well?
221
- */
222
-
223
- space [\t\n\r\f ]
224
- horiz_space [\t\f ]
225
- newline [\n\r ]
226
- non_newline [^ \n\r ]
227
-
228
- comment (" --" {non_newline }* )
229
-
230
- whitespace ({space }+ | {comment })
231
-
232
- /*
233
- * SQL requires at least one newline in the whitespace separating
234
- * string literals that are to be concatenated. Silly, but who are we
235
- * to argue? Note that {whitespace_with_newline} should not have * after
236
- * it, whereas {whitespace} should generally have a * after it...
237
- */
238
-
239
- special_whitespace ({space }+ | {comment }{newline })
240
- horiz_whitespace ({horiz_space }| {comment })
241
- whitespace_with_newline ({horiz_whitespace }* {newline }{special_whitespace }* )
242
-
243
241
other .
244
242
245
243
/*
@@ -261,7 +259,9 @@ other.
261
259
token_start =NULL ;
262
260
%}
263
261
264
- {whitespace }{/* ignore */ }
262
+ {whitespace }{
263
+ /* ignore */
264
+ }
265
265
266
266
{xcstart }{
267
267
token_start = yytext;
@@ -288,9 +288,13 @@ other.
288
288
xcdepth--;
289
289
}
290
290
291
- <xc >{xcinside }{/* ignore */ }
291
+ <xc >{xcinside }{
292
+ /* ignore */
293
+ }
292
294
293
- <xc >{op_chars }{/* ignore */ }
295
+ <xc >{op_chars }{
296
+ /* ignore */
297
+ }
294
298
295
299
<xc ><<EOF>> {yyerror (" unterminated /* comment" ); }
296
300
@@ -319,9 +323,8 @@ other.
319
323
<xb >{xbcat }{
320
324
/* ignore */
321
325
}
322
- <xb ><<EOF>> {
323
- yyerror (" unterminated bit string literal" );
324
- }
326
+ <xb ><<EOF>> {yyerror (" unterminated bit string literal" ); }
327
+
325
328
{xhstart }{
326
329
/* Hexadecimal bit type.
327
330
* At some point we should simply pass the string
@@ -358,7 +361,6 @@ other.
358
361
return keyword->value ;
359
362
}
360
363
361
-
362
364
{xqstart }{
363
365
token_start = yytext;
364
366
BEGIN (xq);
@@ -387,7 +389,6 @@ other.
387
389
}
388
390
<xq ><<EOF>> {yyerror (" unterminated quoted string" ); }
389
391
390
-
391
392
{xdstart }{
392
393
token_start = yytext;
393
394
BEGIN (xd);
@@ -421,9 +422,13 @@ other.
421
422
}
422
423
<xd ><<EOF>> {yyerror (" unterminated quoted identifier" ); }
423
424
424
- {typecast }{return TYPECAST; }
425
+ {typecast }{
426
+ return TYPECAST;
427
+ }
425
428
426
- {self }{return yytext[0 ]; }
429
+ {self }{
430
+ return yytext[0 ];
431
+ }
427
432
428
433
{operator }{
429
434
/*
@@ -571,7 +576,9 @@ other.
571
576
return IDENT;
572
577
}
573
578
574
- {other }{return yytext[0 ]; }
579
+ {other }{
580
+ return yytext[0 ];
581
+ }
575
582
576
583
%%
577
584