Fix ecpg dependency on postgres.h - Mailing list pgsql-patches

From Zdenek Kotala
Subject Fix ecpg dependency on postgres.h
Date
Msg-id 4721B090.4020100@sun.com
Whole thread Raw
Responses Re: Fix ecpg dependency on postgres.h
List pgsql-patches
I attached the patch which fix ecpg dependency on postgresql.h. This was
discussed on hackers:

http://archives.postgresql.org/pgsql-hackers/2007-10/msg01261.php

Directory pgsql/src/interfaces/ecpg/preproc/parser should be removed and
there is new file pgsql/src/interfaces/ecpg/preproc/parser.c which is
little bit modified version (only different headers are included) of
pgsql/src/backend/parser/parser.c.


        Zdenek
diff -rc pgsql/src/interfaces/ecpg/preproc/Makefile pgsql_ecpg/src/interfaces/ecpg/preproc/Makefile
*** pgsql/src/interfaces/ecpg/preproc/Makefile    Wed Aug 22 10:20:58 2007
--- pgsql_ecpg/src/interfaces/ecpg/preproc/Makefile    Fri Oct 26 09:59:40 2007
***************
*** 59,67 ****

  c_keywords.o keywords.o preproc.o parser.o: preproc.h

- parser.c: $(top_srcdir)/src/backend/parser/parser.c
-     rm -f $@ && $(LN_S) $< .
-
  distprep: $(srcdir)/preproc.c $(srcdir)/preproc.h $(srcdir)/pgc.c

  install: all installdirs
--- 59,64 ----
***************
*** 74,80 ****
      rm -f '$(DESTDIR)$(bindir)/ecpg$(X)'

  clean distclean:
!     rm -f *.o ecpg$(X) parser.c
  # garbage from partial builds
      @rm -f y.tab.c y.tab.h
  # garbage from development
--- 71,77 ----
      rm -f '$(DESTDIR)$(bindir)/ecpg$(X)'

  clean distclean:
!     rm -f *.o ecpg$(X)
  # garbage from partial builds
      @rm -f y.tab.c y.tab.h
  # garbage from development
Only in pgsql/src/interfaces/ecpg/preproc: parser
diff -rc pgsql/src/interfaces/ecpg/preproc/parser.c pgsql_ecpg/src/interfaces/ecpg/preproc/parser.c
*** pgsql/src/interfaces/ecpg/preproc/parser.c    Fri Oct 26 09:54:55 2007
--- pgsql_ecpg/src/interfaces/ecpg/preproc/parser.c    Fri Oct 26 10:01:28 2007
***************
*** 0 ****
--- 1,169 ----
+ /*-------------------------------------------------------------------------
+  *
+  * parser.c
+  *        Main entry point/driver for PostgreSQL grammar
+  *
+  * Note that the grammar is not allowed to perform any table access
+  * (since we need to be able to do basic parsing even while inside an
+  * aborted transaction).  Therefore, the data structures returned by
+  * the grammar are "raw" parsetrees that still need to be analyzed by
+  * analyze.c and related files.
+  *
+  *
+  * Portions Copyright (c) 1996-2007, PostgreSQL Global Development Group
+  * Portions Copyright (c) 1994, Regents of the University of California
+  *
+  * IDENTIFICATION
+  *      $PostgreSQL: pgsql/src/backend/parser/parser.c,v 1.70 2007/01/06 19:14:17 tgl Exp $
+  *
+  *-------------------------------------------------------------------------
+  */
+
+ #include "extern.h"
+ #include "preproc.h"
+ #include "nodes/pg_list.h"
+
+
+ List       *parsetree;            /* result of parsing is left here */
+
+ static bool have_lookahead;            /* is lookahead info valid? */
+ static int    lookahead_token;        /* one-token lookahead */
+ static YYSTYPE lookahead_yylval;    /* yylval for lookahead token */
+ static YYLTYPE lookahead_yylloc;    /* yylloc for lookahead token */
+
+
+ /*
+  * raw_parser
+  *        Given a query in string form, do lexical and grammatical analysis.
+  *
+  * Returns a list of raw (un-analyzed) parse trees.
+  */
+ List *
+ raw_parser(const char *str)
+ {
+     int            yyresult;
+
+     parsetree = NIL;            /* in case grammar forgets to set it */
+     have_lookahead = false;
+
+     scanner_init(str);
+     parser_init();
+
+     yyresult = base_yyparse();
+
+     scanner_finish();
+
+     if (yyresult)                /* error */
+         return NIL;
+
+     return parsetree;
+ }
+
+
+ /*
+  * Intermediate filter between parser and base lexer (base_yylex in scan.l).
+  *
+  * The filter is needed because in some cases the standard SQL grammar
+  * requires more than one token lookahead.    We reduce these cases to one-token
+  * lookahead by combining tokens here, in order to keep the grammar LALR(1).
+  *
+  * Using a filter is simpler than trying to recognize multiword tokens
+  * directly in scan.l, because we'd have to allow for comments between the
+  * words.  Furthermore it's not clear how to do it without re-introducing
+  * scanner backtrack, which would cost more performance than this filter
+  * layer does.
+  */
+ int
+ filtered_base_yylex(void)
+ {
+     int            cur_token;
+     int            next_token;
+     YYSTYPE        cur_yylval;
+     YYLTYPE        cur_yylloc;
+
+     /* Get next token --- we might already have it */
+     if (have_lookahead)
+     {
+         cur_token = lookahead_token;
+         base_yylval = lookahead_yylval;
+         base_yylloc = lookahead_yylloc;
+         have_lookahead = false;
+     }
+     else
+         cur_token = base_yylex();
+
+     /* Do we need to look ahead for a possible multiword token? */
+     switch (cur_token)
+     {
+         case NULLS_P:
+             /*
+              * NULLS FIRST and NULLS LAST must be reduced to one token
+              */
+             cur_yylval = base_yylval;
+             cur_yylloc = base_yylloc;
+             next_token = base_yylex();
+             switch (next_token)
+             {
+                 case FIRST_P:
+                     cur_token = NULLS_FIRST;
+                     break;
+                 case LAST_P:
+                     cur_token = NULLS_LAST;
+                     break;
+                 default:
+                     /* save the lookahead token for next time */
+                     lookahead_token = next_token;
+                     lookahead_yylval = base_yylval;
+                     lookahead_yylloc = base_yylloc;
+                     have_lookahead = true;
+                     /* and back up the output info to cur_token */
+                     base_yylval = cur_yylval;
+                     base_yylloc = cur_yylloc;
+                     break;
+             }
+             break;
+
+         case WITH:
+             /*
+              * WITH CASCADED, LOCAL, or CHECK must be reduced to one token
+              *
+              * XXX an alternative way is to recognize just WITH_TIME and put
+              * the ugliness into the datetime datatype productions instead of
+              * WITH CHECK OPTION.  However that requires promoting WITH to a
+              * fully reserved word.  If we ever have to do that anyway
+              * (perhaps for SQL99 recursive queries), come back and simplify
+              * this code.
+              */
+             cur_yylval = base_yylval;
+             cur_yylloc = base_yylloc;
+             next_token = base_yylex();
+             switch (next_token)
+             {
+                 case CASCADED:
+                     cur_token = WITH_CASCADED;
+                     break;
+                 case LOCAL:
+                     cur_token = WITH_LOCAL;
+                     break;
+                 case CHECK:
+                     cur_token = WITH_CHECK;
+                     break;
+                 default:
+                     /* save the lookahead token for next time */
+                     lookahead_token = next_token;
+                     lookahead_yylval = base_yylval;
+                     lookahead_yylloc = base_yylloc;
+                     have_lookahead = true;
+                     /* and back up the output info to cur_token */
+                     base_yylval = cur_yylval;
+                     base_yylloc = cur_yylloc;
+                     break;
+             }
+             break;
+
+         default:
+             break;
+     }
+
+     return cur_token;
+ }
diff -rc pgsql/src/interfaces/ecpg/preproc/type.h pgsql_ecpg/src/interfaces/ecpg/preproc/type.h
*** pgsql/src/interfaces/ecpg/preproc/type.h    Wed Oct  3 13:11:12 2007
--- pgsql_ecpg/src/interfaces/ecpg/preproc/type.h    Thu Oct 25 20:55:44 2007
***************
*** 1,6 ****
--- 1,7 ----
  #ifndef _ECPG_PREPROC_TYPE_H
  #define _ECPG_PREPROC_TYPE_H

+ #include "postgres_fe.h"
  #include "ecpgtype.h"

  struct ECPGtype;


pgsql-patches by date:

Previous
From: Joe Conway
Date:
Subject: Re: [GENERAL] Crosstab Problems
Next
From: Heikki Linnakangas
Date:
Subject: Re: Autovacuum cancellation