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

749 lines
18 KiB
Plaintext
Raw Normal View History

%{
/*-------------------------------------------------------------------------
*
* pgc.l
* lexical scanner for ecpg
*
* This is a modified version of src/backend/parser/scan.l
*
*
* Copyright (c) 1994, Regents of the University of California
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/interfaces/ecpg/preproc/pgc.l,v 1.48 2000/01/20 05:23:26 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);
int before_comment;
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];
%}
%option yylineno
%s C SQL incl def def_ident
/* 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.
* INITIAL is the starting condition, to which all non-conditional rules apply.
* When in an exclusive condition, only those rules defined for that condition apply.
*
* Exclusive states change parsing rules while the state is active.
* There are 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
*
* The "extended comment" syntax closely resembles allowable operator syntax.
* So, when in condition <xc>, only strings which would terminate the
* "extended comment" trigger any action other than "ignore".
* Be sure to match _any_ candidate comment, including those with appended
* operator-like symbols. - thomas 1997-07-14
*/
%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}
xbinside [^']*
xbcat {quote}{space}*\n{space}*{quote}
/* Hexadecimal number
*/
xhstart [xX]{quote}
xhstop {quote}
xhinside [^']*
xhcat {quote}{space}*\n{space}*{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}
xqinside [^\\']*
xqliteral [\\](.|\n)
xqcat {quote}{space}*\n{space}*{quote}
/* Delimited quote
* Allows embedded spaces and other special characters into identifiers.
*/
dquote \"
xdstart {dquote}
xdstop {dquote}
xdinside [^"]*
1999-09-17 11:48:25 +02:00
/* special stuff for C strings */
xdcqq \\\\
xdcqdq \\\"
xdcother [^"]
xdcinside ({xdcqq}|{xdcqdq}|{xdcother})
/* Comments
* Ignored by the scanner and parser.
*/
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
xcline [\/][\*].*[\*][\/]{line_end}+
xcstart [\/][\*]{op_and_self}*
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
xcstop {op_and_self}*[\*][\/]{space_or_nl}*
xcinside [^*]*
xcstar [^/]
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}
1999-10-15 21:02:08 +02:00
comment ("--"|"//").*
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]
line_end {space}*\n
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
*/
%%
<SQL>{comment} { /* ignore */ }
1999-04-13 14:36:38 +02:00
{xcline} { ECHO; }
1999-04-13 14:36:38 +02:00
<xc>{xcstar} { ECHO; }
{xcstart} {
before_comment = YYSTATE;
1999-04-13 14:36:38 +02:00
ECHO;
BEGIN(xc);
}
1999-04-13 14:36:38 +02:00
<xc>{xcstop} { ECHO; BEGIN(before_comment); }
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)
yyerror("ERROR: Bad binary integer input!");
1998-09-01 05:29:17 +02:00
return ICONST;
}
<xh>{xhinside} |
<xb>{xbinside} {
addlit(yytext, yyleng);
}
<xh>{xhcat} |
<xb>{xbcat} {
}
<SQL>{xhstart} {
BEGIN(xh);
startlit();
}
<xh>{xhstop} {
char* endptr;
BEGIN(SQL);
errno = 0;
yylval.ival = strtol(literalbuf, &endptr, 16);
if (*endptr != '\0' || errno == ERANGE)
yyerror("ERROR: Bad hexadecimal integer input");
1998-09-01 05:29:17 +02:00
return ICONST;
}
<SQL>{xqstart} {
BEGIN(xq);
startlit();
}
<xq>{xqstop} {
BEGIN(SQL);
yylval.str = mm_strdup(literalbuf);
1998-09-01 05:29:17 +02:00
return SCONST;
}
<xq>{xqdouble} |
<xq>{xqinside} |
<xq>{xqliteral} {
addlit(yytext, yyleng);
}
<xq>{xqcat} {
}
<SQL>{xdstart} {
BEGIN(xd);
startlit();
}
<xd>{xdstop} {
BEGIN(SQL);
yylval.str = mm_strdup(literalbuf);
1998-09-01 05:29:17 +02:00
return CSTRING;
}
<xd>{xdinside} {
addlit(yytext, yyleng);
}
{xdstart} {
BEGIN(xdc);
startlit();
}
<xdc>{xdstop} {
BEGIN(C);
yylval.str = mm_strdup(literalbuf);
1998-09-01 05:29:17 +02:00
return CSTRING;
}
1999-06-24 15:15:31 +02:00
<xdc>{xdcinside} {
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];
}
<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} {
yylval.ival = atoi((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;
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);
return SCONST;
}
1998-09-01 05:29:17 +02:00
return ICONST;
}
{decimal} {
char* endptr;
1999-06-10 21:11:33 +02:00
if (strlen((char *)yytext) <= 17)
{
errno = 0;
yylval.dval = strtod((char *)yytext,&endptr);
1999-06-10 21:11:33 +02:00
if (*endptr != '\0' || errno == ERANGE)
yyerror("ERROR: Bad float8 input");
return FCONST;
}
yylval.str = mm_strdup((char*)yytext);
return SCONST;
}
1999-04-13 14:36:38 +02:00
<C,SQL>{real} {
char* endptr;
errno = 0;
yylval.dval = strtod((char *)yytext,&endptr);
if (*endptr != '\0' || errno == ERANGE)
yyerror("ERROR: Bad float input");
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]);
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;
}
}
}
}
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>{space_or_nl} { /* ignore */ }
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 ) {
yyerror("ERROR: missing matching 'EXEC SQL IFDEF / EXEC SQL IFNDEF'");
}
else if ( stacked_if_value[preproc_tos].else_branch ) {
yyerror("ERROR: missing 'EXEC SQL ENDIF;'");
}
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 ) {
yyerror("ERROR: duplicated 'EXEC SQL ELSE;'");
}
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 ) {
yyerror("ERROR: unmatched 'EXEC SQL ENDIF;'");
}
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 ) {
yyerror("ERROR: too many nested 'EXEC SQL IFDEF' conditions");
}
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;
yyerror("ERROR: missing 'EXEC SQL ENDIF;'");
}
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;
}