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

866 lines
23 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.59 2000/06/14 18:17:54 petere 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 - thomas 1997-07-12
* <xd> delimited identifiers (double-quoted identifiers) - thomas 1997-10-27
* <xh> hexadecimal numeric string - thomas 1997-11-16
* <xq> quoted strings - thomas 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})
/* C-style comments
*
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! Also, if we
* have something like plus-slash-star, lex will think this is a 3-character
* operator whereas we want to see it as a + operator and a comment start.
2000-03-15 20:09:10 +01:00
* The solution is two-fold:
* 1. append {op_chars}* to xcstart so that it matches as much text as
2000-03-15 20:09:10 +01:00
* {operator} would. Then the tie-breaker (first matching rule of same
* length) ensures xcstart wins. We put back the extra stuff with yyless()
* in case it contains a star-slash that should terminate the comment.
* 2. In the operator rule, check for slash-star within the operator, and
* if found throw it back with yyless(). This handles the plus-slash-star
* problem.
* SQL92-style comments, which start with dash-dash, have similar interactions
* with the operator rule.
*/
xcstart \/\*{op_chars}*
2000-02-22 20:57:12 +01:00
xcstop \*+\/
xcinside ([^*]+)|(\*+[^/])
digit [0-9]
letter [\200-\377_A-Za-z]
letter_or_digit [\200-\377_A-Za-z0-9]
identifier {letter}{letter_or_digit}*
typecast "::"
/*
* "self" is the set of chars that should be returned as single-character
* tokens. "op_chars" is the set of chars that can make up "Op" tokens,
* which can be one or more characters long (but if a single-char token
* appears in the "self" set, it is not to be returned as an Op). Note
* that the sets overlap, but each has some chars that are not in the other.
*
* If you change either set, adjust the character lists appearing in the
* rule for "operator"!
*/
1999-07-19 14:37:48 +02:00
self [,()\[\].;$\:\+\-\*\/\%\^\<\>\=\|]
op_chars [\~\!\@\#\^\&\|\`\?\$\:\+\-\*\/\%\<\>\=]
operator {op_chars}+
/* 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}*)
2000-02-22 20:57:12 +01:00
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. thomas - 1997-09-08
*
* Quoted strings must allow some special characters such as single-quote
* and newline.
2000-03-15 20:09:10 +01:00
* Embedded single-quotes are implemented both in the SQL92-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-03-15 20:09:10 +01:00
* Note that xcstart 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 */ }
{xcstart} {
2000-03-03 10:56:03 +01:00
state_before = YYSTATE;
BEGIN(xc);
2000-03-15 20:09:10 +01:00
/* Put back any characters past slash-star; see above */
yyless(2);
2000-03-30 13:41:46 +02:00
fputs("/*", yyout);
}
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; }
2000-03-15 20:09:10 +01:00
<xc><<EOF>> { mmerror(ET_ERROR, "Unterminated /* comment"); }
<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;
}
2000-03-15 20:09:10 +01:00
<xh>{xhinside} |
<xb>{xbinside} {
addlit(yytext, yyleng);
}
<xh>{xhcat} |
<xb>{xbcat} {
/* ignore */
}
<xb><<EOF>> { mmerror(ET_ERROR, "Unterminated binary integer"); }
<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;
}
<xh><<EOF>> { mmerror(ET_ERROR, "Unterminated hexadecimal integer"); }
2000-03-15 20:09:10 +01:00
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-15 20:09:10 +01:00
<xq><<EOF>> { mmerror(ET_ERROR, "Unterminated quoted string"); }
2000-03-30 13:41:46 +02:00
<SQL>{xdstart} {
2000-03-03 10:56:03 +01:00
state_before = YYSTATE;
BEGIN(xd);
startlit();
}
2000-03-30 13:41:46 +02:00
<xd,xdc>{xdstop} {
2000-03-03 10:56:03 +01:00
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);
}
2000-03-30 13:41:46 +02:00
<xd,xdc><<EOF>> { mmerror(ET_ERROR, "Unterminated quoted identifier"); }
{xdstart} {
state_before = YYSTATE;
BEGIN(xdc);
startlit();
}
<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];
}
2000-03-03 10:56:03 +01:00
<SQL>{operator} {
/*
* Check for embedded slash-star or dash-dash; those
* are comment starts, so operator must stop there.
* Note that slash-star or dash-dash at the first
* character will match a prior rule, not this one.
*/
int nchars = yyleng;
char *slashstar = strstr((char*)yytext, "/*");
char *dashdash = strstr((char*)yytext, "--");
2000-03-15 20:09:10 +01:00
if (slashstar && dashdash)
{
/* if both appear, take the first one */
2000-03-15 20:09:10 +01:00
if (slashstar > dashdash)
slashstar = dashdash;
}
else if (!slashstar)
slashstar = dashdash;
if (slashstar)
nchars = slashstar - ((char*)yytext);
/*
* For SQL92 compatibility, '+' and '-' cannot be the
* last char of a multi-char operator unless the operator
* contains chars that are not in SQL92 operators.
* The idea is to lex '=-' as two operators, but not
* to forbid operator names like '?-' that could not be
* sequences of SQL92 operators.
*/
while (nchars > 1 &&
(yytext[nchars-1] == '+' ||
yytext[nchars-1] == '-'))
{
int ic;
for (ic = nchars-2; ic >= 0; ic--)
{
if (strchr("~!@#&`?$:%^|", yytext[ic]))
break;
}
if (ic >= 0)
break; /* found a char that makes it OK */
nchars--; /* else remove the +/-, and check again */
}
if (nchars < yyleng)
2000-03-15 20:09:10 +01:00
{
/* Strip the unwanted chars from the token */
2000-03-15 20:09:10 +01:00
yyless(nchars);
/*
* If what we have left is only one char, and it's
2000-03-15 20:09:10 +01:00
* one of the characters matching "self", then
* return it as a character token the same way
* that the "self" rule would have.
*/
if (nchars == 1 &&
strchr(",()[].;$:+-*/%^<>=|", yytext[0]))
return yytext[0];
}
/* Convert "!=" operator to "<>" for compatibility */
2000-03-15 20:09:10 +01:00
if (strcmp((char*)yytext, "!=") == 0)
yylval.str = mm_strdup("<>");
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((int)lower_text[i]) && isupper((int) 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((int) yytext[i]); i-- ) {}
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
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((int) yytext[i]); i-- ) {}
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
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;
2000-04-05 11:05:40 +02:00
yylineno = 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
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;
}