postgresql/src/interfaces/ecpg/preproc/pgc.l

774 lines
20 KiB
Plaintext
Raw Normal View History

%{
/*-------------------------------------------------------------------------
*
* pgc.l
* lexical scanner for ecpg
*
* This is a modified version of src/backend/parser/scan.l
*
*
* Portions Copyright (c) 1996-2000, PostgreSQL, Inc
* Portions Copyright (c) 1994, Regents of the University of California
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/interfaces/ecpg/preproc/pgc.l,v 1.53 2000/03/08 22:03:12 tgl Exp $
*
*-------------------------------------------------------------------------
*/
#include <ctype.h>
#include <sys/types.h>
#include <limits.h>
#include <errno.h>
#include "postgres.h"
#include "miscadmin.h"
#include "nodes/parsenodes.h"
#include "nodes/pg_list.h"
#include "parser/scansup.h"
#include "extern.h"
#include "preproc.h"
#include "utils/builtins.h"
/* some versions of lex define this as a macro */
#if defined(yywrap)
#undef yywrap
#endif /* yywrap */
extern YYSTYPE yylval;
/*
* literalbuf is used to accumulate literal values when multiple rules
* are needed to parse a single literal. Call startlit to reset buffer
* to empty, addlit to add text. Note that the buffer is permanently
* malloc'd to the largest size needed so far in the current run.
*/
static char *literalbuf = NULL; /* expandable buffer */
static int literallen; /* actual current length */
static int literalalloc; /* current allocated buffer size */
#define startlit() (literalbuf[0] = '\0', literallen = 0)
static void addlit(char *ytext, int yleng);
2000-03-03 10:56:03 +01:00
int state_before;
struct _yy_buffer { YY_BUFFER_STATE buffer;
long lineno;
char * filename;
struct _yy_buffer * next;
} *yy_buffer = NULL;
static char *old;
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
#define MAX_NESTED_IF 128
static short preproc_tos;
static short ifcond;
static struct _if_value {
short condition;
short else_branch;
} stacked_if_value[MAX_NESTED_IF];
%}
2000-02-22 20:57:12 +01:00
%option yylineno
%s C SQL incl def def_ident
2000-02-22 20:57:12 +01:00
/*
* OK, here is a short description of lex/flex rules behavior.
* The longest pattern which matches an input string is always chosen.
* For equal-length patterns, the first occurring in the rules list is chosen.
2000-02-22 20:57:12 +01:00
* INITIAL is the starting state, to which all non-conditional rules apply.
* Exclusive states change parsing rules while the state is active. When in
* an exclusive state, only those rules defined for that state apply.
*
2000-02-22 20:57:12 +01:00
* We use exclusive states for quoted strings, extended comments,
* and to eliminate parsing troubles for numeric strings.
* Exclusive states:
* <xb> binary numeric string - thomas 1997-11-16
* <xc> extended C-style comments - tgl 1997-07-12
* <xd> delimited identifiers (double-quoted identifiers) - tgl 1997-10-27
* <xh> hexadecimal numeric string - thomas 1997-11-16
* <xq> quoted strings - tgl 1997-07-30
*/
%x xb
%x xc
%x xd
%x xdc
%x xh
%x xq
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
%x xpre
%x xcond
%x xskip
/* Binary number
*/
xbstart [bB]{quote}
xbstop {quote}
2000-02-22 20:57:12 +01:00
xbinside [^']+
xbcat {quote}{whitespace_with_newline}{quote}
/* Hexadecimal number
*/
xhstart [xX]{quote}
xhstop {quote}
2000-02-22 20:57:12 +01:00
xhinside [^']+
xhcat {quote}{whitespace_with_newline}{quote}
1999-10-15 21:02:08 +02:00
/* C version of hex number
*/
xch 0[xX][0-9A-Fa-f]*
/* Extended quote
* xqdouble implements SQL92 embedded quote
* xqcat allows strings to cross input lines
*/
quote '
xqstart {quote}
xqstop {quote}
xqdouble {quote}{quote}
2000-02-22 20:57:12 +01:00
xqinside [^\\']+
xqliteral [\\](.|\n)
2000-02-22 20:57:12 +01:00
xqcat {quote}{whitespace_with_newline}{quote}
/* Delimited quote
* Allows embedded spaces and other special characters into identifiers.
*/
dquote \"
xdstart {dquote}
xdstop {dquote}
2000-02-22 20:57:12 +01:00
xdinside [^"]+
1999-09-17 11:48:25 +02:00
/* special stuff for C strings */
xdcqq \\\\
xdcqdq \\\"
xdcother [^"]
xdcinside ({xdcqq}|{xdcqdq}|{xdcother})
2000-02-22 20:57:12 +01:00
/* C-Style Comments
* Ignored by the scanner and parser.
2000-02-22 20:57:12 +01:00
* The "extended comment" syntax closely resembles allowable operator syntax.
* The tricky part here is to get lex to recognize a string starting with
* slash-star as a comment, when interpreting it as an operator would produce
* a longer match --- remember lex will prefer a longer match! So, we have
* to provide a special rule for xcline (a complete comment that could
* otherwise look like an operator), as well as append {op_and_self}* to
* xcstart so that it matches at least as much as {operator} would.
* Then the tie-breaker (first matching rule of same length) wins.
* There is still a problem if someone writes, eg, slash-star-star-slash-plus.
* It'll be taken as an xcstart, rather than xcline and an operator as one
* could wish. I don't see any way around that given lex's behavior;
* that someone will just have to write a space after the comment.
*/
2000-02-22 20:57:12 +01:00
xcline \/\*{op_and_self}*\*\/
xcstart \/\*{op_and_self}*
xcstop \*+\/
xcinside ([^*]+)|(\*+[^/])
digit [0-9]
letter [\200-\377_A-Za-z]
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
letter_or_digit [\200-\377_A-Za-z0-9]
identifier {letter}{letter_or_digit}*
typecast "::"
1999-07-19 14:37:48 +02:00
self [,()\[\].;$\:\+\-\*\/\%\^\<\>\=\|]
1999-09-17 11:48:25 +02:00
op_and_self [\~\!\@\#\^\&\|\`\?\$\:\+\-\*\/\%\<\>\=]
operator {op_and_self}+
/* we no longer allow unary minus in numbers.
* instead we pass it separately to parser. there it gets
* coerced via doNegate() -- Leon aug 20 1999
1999-10-08 13:05:05 +02:00
*/
1999-10-08 13:05:05 +02:00
integer {digit}+
decimal (({digit}*\.{digit}+)|({digit}+\.{digit}*))
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
real ((({digit}*\.{digit}+)|({digit}+\.{digit}*)|({digit}+))([Ee][-+]?{digit}+))
param \${integer}
2000-02-22 20:57:12 +01:00
/*
* 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. SQL92-style comments, which 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?
*/
1999-03-24 21:05:15 +01:00
ccomment "//".*\n
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
space [ \t\r\f]
space_or_nl [ \t\r\f\n]
2000-02-22 20:57:12 +01:00
line_end {space}*\n
horiz_space [ \t\f]
newline [\n\r]
non_newline [^\n\r]
comment (("--"|"//"){non_newline}*)
whitespace ({space}|{comment})
/*
* SQL92 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...
*/
horiz_whitespace ({horiz_space}|{comment})
whitespace_with_newline ({horiz_whitespace}*{newline}{whitespace}*)
other .
/* some stuff needed for ecpg */
exec [eE][xX][eE][cC]
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
sql [sS][qQ][lL]
define [dD][eE][fF][iI][nN][eE]
include [iI][nN][cC][lL][uU][dD][eE]
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
ifdef [iI][fF][dD][eE][fF]
ifndef [iI][fF][nN][dD][eE][fF]
else [eE][lL][sS][eE]
elif [eE][lL][iI][fF]
endif [eE][nN][dD][iI][fF]
exec_sql {exec}{space_or_nl}*{sql}{space_or_nl}*
/* Take care of cpp continuation lines */
cppline {space}*#(.*\\{line_end})*.*
/* DO NOT PUT ANY COMMENTS IN THE FOLLOWING SECTION.
* AT&T lex does not properly handle C-style comments in this second lex block.
* So, put comments here. tgl - 1997-09-08
*
* Quoted strings must allow some special characters such as single-quote
* and newline.
* Embedded single-quotes are implemented both in the SQL/92-standard
* style of two adjacent single quotes "''" and in the Postgres/Java style
* of escaped-quote "\'".
* Other embedded escaped characters are matched explicitly and the leading
* backslash is dropped from the string. - thomas 1997-09-24
2000-02-22 20:57:12 +01:00
* Note that xcline must appear before xcstart, which must appear before
* operator, as explained above! Also whitespace (comment) must appear
* before operator.
*/
%%
2000-02-22 20:57:12 +01:00
<SQL>{whitespace} { /* ignore */ }
1999-04-13 14:36:38 +02:00
{xcline} { ECHO; }
{xcstart} {
2000-03-03 10:56:03 +01:00
state_before = YYSTATE;
1999-04-13 14:36:38 +02:00
ECHO;
BEGIN(xc);
}
2000-03-03 10:56:03 +01:00
<xc>{xcstop} { ECHO; BEGIN(state_before); }
1999-04-13 14:36:38 +02:00
<xc>{xcinside} { ECHO; }
<SQL>{xbstart} {
BEGIN(xb);
startlit();
}
<xb>{xbstop} {
char* endptr;
BEGIN(SQL);
errno = 0;
yylval.ival = strtol(literalbuf, &endptr, 2);
if (*endptr != '\0' || errno == ERANGE)
2000-01-27 20:01:35 +01:00
mmerror(ET_ERROR, "Bad binary integer input!");
1998-09-01 05:29:17 +02:00
return ICONST;
}
<xh>{xhinside} |
<xb>{xbinside} {
addlit(yytext, yyleng);
}
<xh>{xhcat} |
2000-02-22 20:57:12 +01:00
<xb>{xbcat} { /* ignore */
}
<SQL>{xhstart} {
BEGIN(xh);
startlit();
}
2000-03-03 10:56:03 +01:00
<xh>{xhstop} {
char* endptr;
BEGIN(SQL);
errno = 0;
yylval.ival = strtol(literalbuf, &endptr, 16);
if (*endptr != '\0' || errno == ERANGE)
2000-01-27 20:01:35 +01:00
mmerror(ET_ERROR, "Bad hexadecimal integer input");
1998-09-01 05:29:17 +02:00
return ICONST;
}
2000-03-03 10:56:03 +01:00
{xqstart} {
state_before = YYSTATE;
BEGIN(xq);
startlit();
}
2000-03-03 10:56:03 +01:00
<xq>{xqstop} {
BEGIN(state_before);
yylval.str = mm_strdup(literalbuf);
1998-09-01 05:29:17 +02:00
return SCONST;
}
<xq>{xqdouble} |
<xq>{xqinside} |
2000-03-03 10:56:03 +01:00
<xq>{xqliteral} {
addlit(yytext, yyleng);
}
2000-03-03 10:56:03 +01:00
<xq>{xqcat} {
/* ignore */
}
2000-03-03 10:56:03 +01:00
{xdstart} {
state_before = YYSTATE;
BEGIN(xd);
startlit();
}
2000-03-03 10:56:03 +01:00
<xd>{xdstop} {
BEGIN(state_before);
yylval.str = mm_strdup(literalbuf);
1998-09-01 05:29:17 +02:00
return CSTRING;
}
2000-03-03 10:56:03 +01:00
<xd>{xdinside} {
addlit(yytext, yyleng);
}
<SQL>{typecast} { return TYPECAST; }
1999-03-20 20:46:54 +01:00
<SQL>{self} { /*
* We may find a ';' inside a structure
* definition in a TYPE or VAR statement.
* This is not an EOL marker.
*/
if (yytext[0] == ';' && struct_level == 0)
BEGIN C;
return yytext[0];
}
2000-03-03 10:56:03 +01:00
<SQL>{operator} {
if (strcmp((char*)yytext,"!=") == 0)
yylval.str = mm_strdup("<>"); /* compatability */
else
yylval.str = mm_strdup((char*)yytext);
1998-09-01 05:29:17 +02:00
return Op;
}
<SQL>{param} {
2000-02-22 20:57:12 +01:00
yylval.ival = atol((char*)&yytext[1]);
1998-09-01 05:29:17 +02:00
return PARAM;
}
1999-04-13 14:36:38 +02:00
<C,SQL>{integer} {
char* endptr;
errno = 0;
2000-02-22 20:57:12 +01:00
yylval.ival = strtol((char *)yytext, &endptr,10);
if (*endptr != '\0' || errno == ERANGE)
{
errno = 0;
1999-06-10 21:11:33 +02:00
yylval.str = mm_strdup((char*)yytext);
2000-02-22 20:57:12 +01:00
return FCONST;
}
1998-09-01 05:29:17 +02:00
return ICONST;
}
{decimal} {
yylval.str = mm_strdup((char*)yytext);
2000-02-22 20:57:12 +01:00
return FCONST;
}
1999-04-13 14:36:38 +02:00
<C,SQL>{real} {
2000-02-22 20:57:12 +01:00
yylval.str = mm_strdup((char*)yytext);
1998-09-01 05:29:17 +02:00
return FCONST;
}
<SQL>:{identifier}(("->"|\.){identifier})* {
yylval.str = mm_strdup((char*)yytext+1);
return(CVARIABLE);
}
<SQL>{identifier} {
int i;
ScanKeyword *keyword;
char lower_text[NAMEDATALEN];
/* this should leave the last byte set to '\0' */
strncpy(lower_text, yytext, NAMEDATALEN-1);
for(i = 0; lower_text[i]; i++)
if (isascii((unsigned char)lower_text[i]) && isupper(lower_text[i]))
lower_text[i] = tolower(lower_text[i]);
2000-01-27 20:01:35 +01:00
if (i >= NAMEDATALEN)
{
sprintf(errortext, "Identifier \"%s\" will be truncated to \"%.*s\"", yytext, NAMEDATALEN-1, yytext);
mmerror (ET_WARN, errortext);
yytext[NAMEDATALEN-1] = '\0';
}
keyword = ScanKeywordLookup((char*)lower_text);
if (keyword != NULL) {
1998-09-01 05:29:17 +02:00
return keyword->value;
}
else
{
keyword = ScanECPGKeywordLookup((char*)lower_text);
if (keyword != NULL) {
1998-09-01 05:29:17 +02:00
return keyword->value;
}
else
{
struct _defines *ptr;
for (ptr = defines; ptr; ptr = ptr->next)
{
if (strcmp(yytext, ptr->old) == 0)
{
struct _yy_buffer *yb;
yb = mm_alloc(sizeof(struct _yy_buffer));
yb->buffer = YY_CURRENT_BUFFER;
yb->lineno = yylineno;
yb->filename = mm_strdup(input_filename);
yb->next = yy_buffer;
yy_buffer = yb;
yy_scan_string(ptr->new);
break;
}
}
if (ptr == NULL)
{
yylval.str = mm_strdup((char*)yytext);
1998-09-01 05:29:17 +02:00
return IDENT;
}
}
}
}
1998-09-01 05:29:17 +02:00
<SQL>{other} { return yytext[0]; }
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
<C>{exec_sql} { BEGIN SQL; return SQL_START; }
<C>{ccomment} { /* ignore */ }
1999-10-15 21:02:08 +02:00
<C>{xch} {
char* endptr;
errno = 0;
yylval.ival = strtol((char *)yytext,&endptr,16);
if (*endptr != '\0' || errno == ERANGE)
{
errno = 0;
yylval.str = mm_strdup((char*)yytext);
return SCONST;
1999-10-15 21:02:08 +02:00
}
return ICONST;
}
<C>{cppline} {
yylval.str = mm_strdup((char*)yytext);
return(CPP_LINE);
}
<C>{identifier} {
ScanKeyword *keyword;
keyword = ScanCKeywordLookup((char*)yytext);
if (keyword != NULL) {
1998-09-01 05:29:17 +02:00
return keyword->value;
}
else
{
struct _defines *ptr;
for (ptr = defines; ptr; ptr = ptr->next)
{
if (strcmp(yytext, ptr->old) == 0)
{
struct _yy_buffer *yb;
yb = mm_alloc(sizeof(struct _yy_buffer));
yb->buffer = YY_CURRENT_BUFFER;
yb->lineno = yylineno;
yb->filename = mm_strdup(input_filename);
yb->next = yy_buffer;
yy_buffer = yb;
yy_scan_string(ptr->new);
break;
}
}
if (ptr == NULL)
{
yylval.str = mm_strdup((char*)yytext);
1998-09-01 05:29:17 +02:00
return IDENT;
}
}
}
<C>";" { return(';'); }
<C>"," { return(','); }
<C>"*" { return('*'); }
1999-04-16 14:26:49 +02:00
<C>"%" { return('%'); }
<C>"/" { return('/'); }
<C>"+" { return('+'); }
<C>"-" { return('-'); }
<C>"(" { return('('); }
<C>")" { return(')'); }
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
<C>{space_or_nl} { ECHO; }
<C>\{ { return('{'); }
<C>\} { return('}'); }
<C>\[ { return('['); }
<C>\] { return(']'); }
<C>\= { return('='); }
1999-10-15 21:02:08 +02:00
<C>{other} { return S_ANYTHING; }
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
<C>{exec_sql}{define}{space_or_nl}* { BEGIN(def_ident); }
<C>{exec_sql}{include}{space_or_nl}* { BEGIN(incl); }
<C,xskip>{exec_sql}{ifdef}{space_or_nl}* { ifcond = TRUE; BEGIN(xcond); }
<C,xskip>{exec_sql}{ifndef}{space_or_nl}* { ifcond = FALSE; BEGIN(xcond); }
<C,xskip>{exec_sql}{elif}{space_or_nl}* { /* pop stack */
if ( preproc_tos == 0 ) {
2000-01-27 20:01:35 +01:00
mmerror(ET_FATAL, "Missing matching 'EXEC SQL IFDEF / EXEC SQL IFNDEF'");
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
}
else if ( stacked_if_value[preproc_tos].else_branch ) {
2000-01-27 20:01:35 +01:00
mmerror(ET_FATAL, "Missing 'EXEC SQL ENDIF;'");
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
}
else {
preproc_tos--;
}
ifcond = TRUE; BEGIN(xcond);
}
<C,xskip>{exec_sql}{else}{space_or_nl}*";" { /* only exec sql endif pops the stack, so take care of duplicated 'else' */
if ( stacked_if_value[preproc_tos].else_branch ) {
2000-01-27 20:01:35 +01:00
mmerror(ET_FATAL, "Duplicated 'EXEC SQL ELSE;'");
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
}
else {
stacked_if_value[preproc_tos].else_branch = TRUE;
stacked_if_value[preproc_tos].condition =
(stacked_if_value[preproc_tos-1].condition &&
! stacked_if_value[preproc_tos].condition);
if ( stacked_if_value[preproc_tos].condition ) {
BEGIN(C);
}
else {
BEGIN(xskip);
}
}
}
<C,xskip>{exec_sql}{endif}{space_or_nl}*";" {
if ( preproc_tos == 0 ) {
2000-01-27 20:01:35 +01:00
mmerror(ET_FATAL, "Unmatched 'EXEC SQL ENDIF;'");
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
}
else {
preproc_tos--;
}
if ( stacked_if_value[preproc_tos].condition ) {
BEGIN(C);
}
else {
BEGIN(xskip);
}
}
<xskip>{other} { /* ignore */ }
<xcond>{identifier}{space_or_nl}*";" {
if ( preproc_tos >= MAX_NESTED_IF-1 ) {
2000-01-27 20:01:35 +01:00
mmerror(ET_FATAL, "Too many nested 'EXEC SQL IFDEF' conditions");
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
}
else {
struct _defines *defptr;
unsigned int i;
/* skip the ";" and trailing whitespace. Note that yytext contains
at least one non-space character plus the ";" */
for ( i = strlen(yytext)-2; i > 0 && isspace(yytext[i]); i-- ) {}
yytext[i+1] = '\0';
for ( defptr = defines; defptr != NULL &&
( strcmp((char*)yytext, defptr->old) != 0 ); defptr = defptr->next );
preproc_tos++;
stacked_if_value[preproc_tos].else_branch = FALSE;
stacked_if_value[preproc_tos].condition =
( (defptr ? ifcond : !ifcond) && stacked_if_value[preproc_tos-1].condition );
}
if ( stacked_if_value[preproc_tos].condition ) {
BEGIN C;
}
else {
BEGIN(xskip);
}
}
<def_ident>{identifier} {
old = mm_strdup(yytext);
BEGIN(def);
startlit();
}
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
<def>{space_or_nl}*";" {
struct _defines *ptr, *this;
for (ptr = defines; ptr != NULL; ptr = ptr->next)
{
if (strcmp(old, ptr->old) == 0)
{
free(ptr->new);
/* ptr->new = mm_strdup(scanstr(literalbuf));*/
ptr->new = mm_strdup(literalbuf);
}
}
if (ptr == NULL)
{
this = (struct _defines *) mm_alloc(sizeof(struct _defines));
/* initial definition */
this->old = old;
/* this->new = mm_strdup(scanstr(literalbuf));*/
this->new = mm_strdup(literalbuf);
this->next = defines;
defines = this;
}
BEGIN(C);
}
<def>[^";"] {
addlit(yytext, yyleng);
}
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
<incl>[^";"]+";" { /* got the include file name */
struct _yy_buffer *yb;
struct _include_path *ip;
char inc_file[MAXPGPATH];
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
unsigned int i;
yb = mm_alloc(sizeof(struct _yy_buffer));
yb->buffer = YY_CURRENT_BUFFER;
yb->lineno = yylineno;
yb->filename = input_filename;
yb->next = yy_buffer;
yy_buffer = yb;
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
/* skip the ";" and trailing whitespace. Note that yytext contains
at least one non-space character plus the ";" */
for ( i = strlen(yytext)-2; i > 0 && isspace(yytext[i]); i-- ) {}
yytext[i+1] = '\0';
yyin = NULL;
for (ip = include_paths; yyin == NULL && ip != NULL; ip = ip->next)
{
if (strlen(ip->path) + strlen(yytext) + 3 > MAXPGPATH)
{
fprintf(stderr, "Error: Path %s/%s is too long in line %d, skipping.\n", ip->path, yytext, yylineno);
continue;
}
sprintf (inc_file, "%s/%s", ip->path, yytext);
yyin = fopen( inc_file, "r" );
if (!yyin)
{
if (strcmp(inc_file + strlen(inc_file) - 2, ".h"))
{
strcat(inc_file, ".h");
yyin = fopen( inc_file, "r" );
}
}
}
if (!yyin)
{
fprintf(stderr, "Error: Cannot open include file %s in line %d\n", yytext, yylineno);
exit(NO_INCLUDE_FILE);
}
input_filename = mm_strdup(inc_file);
yy_switch_to_buffer(yy_create_buffer(yyin,YY_BUF_SIZE ));
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
yylineno = 1;
1999-03-24 21:05:15 +01:00
output_line_number();
BEGIN C;
}
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
<<EOF>> {
if ( preproc_tos > 0 ) {
preproc_tos = 0;
2000-01-27 20:01:35 +01:00
mmerror(ET_FATAL, "Missing 'EXEC SQL ENDIF;'");
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
}
if (yy_buffer == NULL)
yyterminate();
else
{
struct _yy_buffer *yb = yy_buffer;
if (yyin != NULL)
fclose(yyin);
yy_delete_buffer( YY_CURRENT_BUFFER );
yy_switch_to_buffer(yy_buffer->buffer);
yylineno = yy_buffer->lineno;
free(input_filename);
input_filename = yy_buffer->filename;
yy_buffer = yy_buffer->next;
free(yb);
1999-03-24 21:05:15 +01:00
output_line_number();
}
}
%%
void
lex_init(void)
{
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
braces_open = 0;
preproc_tos = 0;
ifcond = TRUE;
stacked_if_value[preproc_tos].condition = ifcond;
stacked_if_value[preproc_tos].else_branch = FALSE;
/* initialize literal buffer to a reasonable but expansible size */
if (literalbuf == NULL)
{
literalalloc = 128;
literalbuf = (char *) malloc(literalalloc);
}
startlit();
BEGIN C;
}
static void
addlit(char *ytext, int yleng)
{
/* enlarge buffer if needed */
if ((literallen+yleng) >= literalalloc)
{
do {
literalalloc *= 2;
} while ((literallen+yleng) >= literalalloc);
literalbuf = (char *) realloc(literalbuf, literalalloc);
}
/* append data --- note we assume ytext is null-terminated */
memcpy(literalbuf+literallen, ytext, yleng+1);
literallen += yleng;
}
int yywrap(void)
The first fix is to allow an input file with a relative path and without a ".pgc " extension. The second patch fixes a coredump when there is more than one input file (in that case, cur and types were not set to NULL before processing the second f ile) The patch below modifies the accepted grammar of ecpg to accept FETCH [direction] [amount] cursor name i.e. the IN|FROM clause becomes optional (as in Oracle and Informix). This removes the incompatibility mentioned in section "Porting From Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar is modified in such a way as to avoid shift/reduce conflicts. It does not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar did (this seems to be a bug of the old grammar anyway). This patch cleans up the handling of space characters in the scanner; some patte rns require \n to be in {space}, some do not. A second fix is the handling of cpp continuati on lines; the old pattern did not match these. The parser is patched to fix an off-by-one error in the #line directives. The pa rser is also enhanced to report the correct location of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally, some right recursions in the parser were replaced by left-recursions. This patch adds preprocessor directives to ecpg; in particular EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF "EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and defines, specified on the command line with -D. Defines, specified on the command line are persistent across multiple input files. Defines can be nested up to a maximum level of 128 (see patch). There is a fair amount of error checking to make sure directives are matched properly. I need preprocessor directives for porting code, that is written for an Informix database, to a PostgreSQL database, while maintaining compatibility with the original code. I decided not to extend the already large ecpg grammar. Everything is done in the scanner by adding some states, e.g. to skip all input except newlines and directives. The preprocessor commands are compatible with Informix. Oracle uses a cpp replacement. Rene Hogendoorn
1999-12-21 18:42:16 +01:00
{
return 1;
}