44 * scan.l
55 * lexical scanner for PostgreSQL
66 *
7+ * XXX The rules in this file must be kept in sync with psql's lexer!!!
8+ *
79 * Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group
810 * Portions Copyright (c) 1994, Regents of the University of California
911 *
10- *
1112 * 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 $
1314 *
1415 *-------------------------------------------------------------------------
1516*/
2930#include " utils/builtins.h"
3031#include " mb/pg_wchar.h"
3132
32- /* No reason to constrain amount of data slurped*/
33- #define YY_READ_BUF_SIZE 16777216
34-
3533/* Avoid exit() on fatal scanner errors (a bit ugly -- see yy_fatal_error)*/
3634#define fprintf (file, fmt, msg ) ereport(ERROR, (errmsg_internal(" %s" , msg)))
3735
@@ -103,6 +101,41 @@ unsigned char unescape_single_char(unsigned char c);
103101%x xh
104102%x xq
105103
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+
106139/* Bit string
107140 * It is tempting to scan the string for only those characters
108141 * which are allowed. However, this leads to silently swallowed
@@ -205,41 +238,6 @@ real((({digit}*\.{digit}+)|({digit}+\.{digit}*)|({digit}+))([Ee][-+]?{digit}+
205238
206239param \$ {integer }
207240
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-
243241other .
244242
245243/*
@@ -261,7 +259,9 @@ other.
261259token_start =NULL ;
262260%}
263261
264- {whitespace }{/* ignore */ }
262+ {whitespace }{
263+ /* ignore */
264+ }
265265
266266{xcstart }{
267267token_start = yytext;
@@ -288,9 +288,13 @@ other.
288288xcdepth--;
289289}
290290
291- <xc >{xcinside }{/* ignore */ }
291+ <xc >{xcinside }{
292+ /* ignore */
293+ }
292294
293- <xc >{op_chars }{/* ignore */ }
295+ <xc >{op_chars }{
296+ /* ignore */
297+ }
294298
295299<xc ><<EOF>> {yyerror (" unterminated /* comment" ); }
296300
@@ -319,9 +323,8 @@ other.
319323<xb >{xbcat }{
320324/* ignore */
321325}
322- <xb ><<EOF>> {
323- yyerror (" unterminated bit string literal" );
324- }
326+ <xb ><<EOF>> {yyerror (" unterminated bit string literal" ); }
327+
325328{xhstart }{
326329/* Hexadecimal bit type.
327330 * At some point we should simply pass the string
@@ -358,7 +361,6 @@ other.
358361return keyword->value ;
359362}
360363
361-
362364{xqstart }{
363365token_start = yytext;
364366BEGIN (xq);
@@ -387,7 +389,6 @@ other.
387389}
388390<xq ><<EOF>> {yyerror (" unterminated quoted string" ); }
389391
390-
391392{xdstart }{
392393token_start = yytext;
393394BEGIN (xd);
@@ -421,9 +422,13 @@ other.
421422}
422423<xd ><<EOF>> {yyerror (" unterminated quoted identifier" ); }
423424
424- {typecast }{return TYPECAST; }
425+ {typecast }{
426+ return TYPECAST;
427+ }
425428
426- {self }{return yytext[0 ]; }
429+ {self }{
430+ return yytext[0 ];
431+ }
427432
428433{operator }{
429434/*
@@ -571,7 +576,9 @@ other.
571576return IDENT;
572577}
573578
574- {other }{return yytext[0 ]; }
579+ {other }{
580+ return yytext[0 ];
581+ }
575582
576583%%
577584