From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] ECPG patch for exec sql ifdef etc. |
Date: | 2000-01-08 16:10:01 |
Message-ID: | 200001081610.LAA00441@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I just noticed that this patch added an attribute 'pertinent' to the _defines
> structure. However, I cannot find a reference to this attribute anywhere
> else. Since this happened before I'm afraid I removed some part of the patch
> by committing my own changes I'd like to know what this is supposed to do.
>
> And since I do not know who send the patch I just ask here.
>
> Thanks anyway for this patch.
OK, 1.19 version of type.h shows this, and the diff is attached too.
---------------------------------------------------------------------------
revision 1.19
date: 1999/12/21 17:42:16; author: momjian; state: Exp; lines: +1 -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
---------------------------------------------------------------------------
and the diff shows:
$ pgcvs diff -c -r 1.18 -r 1.19 type.h|less
Index: type.h
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/type.h,v
retrieving revision 1.18
retrieving revision 1.19
diff -c -r1.18 -r1.19
*** type.h 1999/05/25 16:15:04 1.18
--- type.h 1999/12/21 17:42:16 1.19
***************
*** 119,124 ****
--- 119,125 ----
{
char *old;
char *new;
+ int pertinent;
struct _defines *next;
};
--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-01-08 16:15:16 | Re: [HACKERS] Costs: Index vs Non-Index |
Previous Message | Tom Lane | 2000-01-08 16:03:59 | Re: [HACKERS] Re: ERROR: out of free buffers: time to abort ! |