Обсуждение: plpgsql compile failure

Поиск
Список
Период
Сортировка

plpgsql compile failure

От
Bruce Momjian
Дата:
I am seeing the following plpgsql compile failure in CVS:

    #$ gmake
    bison -y -d  gram.y
    NONE:0: /usr/contrib/bin/gm4: ERROR: EOF in string
    sed -e 's/yy/plpgsql_yy/g' -e 's/YY/PLPGSQL_YY/g' < y.tab.c >
    ./pl_gram.c
    /bin/sh: cannot open y.tab.c: no such file
    gmake: *** [pl.tab.h] Error 2

I believe it is related to this commit:

    revision 1.41
    date: 2003/03/25 03:16:40;  author: tgl;  state: Exp;  lines: +29 -6
    plpgsql can assign to subscripted variables now, e.g.
            x[42] := whatever;
    The facility is pretty primitive because it doesn't do array slicing and
    it has the same semantics as array update in SQL (array must already
    be non-null, etc).  But it's a start.

I have attached the change --- anyone see the cause?  I have bison 1.75.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
Index: gram.y
===================================================================
RCS file: /cvsroot/pgsql-server/src/pl/plpgsql/src/gram.y,v
retrieving revision 1.40
retrieving revision 1.41
diff -c -c -r1.40 -r1.41
*** gram.y    10 Nov 2002 00:35:58 -0000    1.40
--- gram.y    25 Mar 2003 03:16:40 -0000    1.41
***************
*** 4,10 ****
   *                          procedural language
   *
   * IDENTIFICATION
!  *      $Header: /cvsroot/pgsql-server/src/pl/plpgsql/src/gram.y,v 1.40 2002/11/10 00:35:58 momjian Exp $
   *
   *      This software is copyrighted by Jan Wieck - Hamburg.
   *
--- 4,10 ----
   *                          procedural language
   *
   * IDENTIFICATION
!  *      $Header: /cvsroot/pgsql-server/src/pl/plpgsql/src/gram.y,v 1.41 2003/03/25 03:16:40 tgl Exp $
   *
   *      This software is copyrighted by Jan Wieck - Hamburg.
   *
***************
*** 105,111 ****
  %type <nsitem>    decl_aliasitem
  %type <str>        decl_stmts decl_stmt

! %type <expr>    expr_until_semi expr_until_then expr_until_loop
  %type <expr>    opt_exitcond

  %type <ival>    assign_var cursor_variable
--- 105,112 ----
  %type <nsitem>    decl_aliasitem
  %type <str>        decl_stmts decl_stmt

! %type <expr>    expr_until_semi expr_until_rightbracket
! %type <expr>    expr_until_then expr_until_loop
  %type <expr>    opt_exitcond

  %type <ival>    assign_var cursor_variable
***************
*** 822,827 ****
--- 823,843 ----
                          check_assignable(yylval.variable);
                          $$ = yylval.variable->dno;
                      }
+                 | assign_var '[' expr_until_rightbracket
+                     {
+                         PLpgSQL_arrayelem    *new;
+
+                         new = malloc(sizeof(PLpgSQL_arrayelem));
+                         memset(new, 0, sizeof(PLpgSQL_arrayelem));
+
+                         new->dtype        = PLPGSQL_DTYPE_ARRAYELEM;
+                         new->subscript    = $3;
+                         new->arrayparentno = $1;
+
+                         plpgsql_adddatum((PLpgSQL_datum *)new);
+
+                         $$ = new->dno;
+                     }
                  ;

  stmt_if            : K_IF lno expr_until_then proc_sect stmt_else K_END K_IF ';'
***************
*** 1491,1496 ****
--- 1507,1516 ----
                      { $$ = plpgsql_read_expression(';', ";"); }
                  ;

+ expr_until_rightbracket :
+                     { $$ = plpgsql_read_expression(']', "]"); }
+                 ;
+
  expr_until_then :
                      { $$ = plpgsql_read_expression(K_THEN, "THEN"); }
                  ;
***************
*** 1577,1592 ****
      for (;;)
      {
          tok = yylex();
!         if (tok == '(')
              parenlevel++;
!         else if (tok == ')')
          {
              parenlevel--;
              if (parenlevel < 0)
                  elog(ERROR, "mismatched parentheses");
          }
-         else if (parenlevel == 0 && tok == until)
-             break;
          /*
           * End of function definition is an error, and we don't expect to
           * hit a semicolon either (unless it's the until symbol, in which
--- 1597,1612 ----
      for (;;)
      {
          tok = yylex();
!         if (tok == until && parenlevel == 0)
!             break;
!         if (tok == '(' || tok == '[')
              parenlevel++;
!         else if (tok == ')' || tok == ']')
          {
              parenlevel--;
              if (parenlevel < 0)
                  elog(ERROR, "mismatched parentheses");
          }
          /*
           * End of function definition is an error, and we don't expect to
           * hit a semicolon either (unless it's the until symbol, in which
***************
*** 1986,1991 ****
--- 2006,2014 ----
              }
              break;
          case PLPGSQL_DTYPE_RECFIELD:
+             /* always assignable? */
+             break;
+         case PLPGSQL_DTYPE_ARRAYELEM:
              /* always assignable? */
              break;
          case PLPGSQL_DTYPE_TRIGARG:

Re: plpgsql compile failure

От
Joe Conway
Дата:
Bruce Momjian wrote:
> I am seeing the following plpgsql compile failure in CVS:
> 
>     #$ gmake
>     bison -y -d  gram.y
>     NONE:0: /usr/contrib/bin/gm4: ERROR: EOF in string
>     sed -e 's/yy/plpgsql_yy/g' -e 's/YY/PLPGSQL_YY/g' < y.tab.c >
>     ./pl_gram.c
>     /bin/sh: cannot open y.tab.c: no such file
>     gmake: *** [pl.tab.h] Error 2
> 
> I believe it is related to this commit:
>     

I'm seeing the same thing, and I also have bison 1.75. I confirmed that 
by reverting the commit, the problem goes away. Possibly bison version 
related?

Joe



Re: plpgsql compile failure

От
Tom Lane
Дата:
Joe Conway <mail@joeconway.com> writes:
> Bruce Momjian wrote:
>> I am seeing the following plpgsql compile failure in CVS:

> I'm seeing the same thing, and I also have bison 1.75.

Considering how trivial the grammar change is, it's hard to call this
anything except a bison bug.  I'd be interested to know what causes it
though --- is it worth trying to invent a workaround so people don't
have to upgrade?
        regards, tom lane



Re: plpgsql compile failure

От
Bruce Momjian
Дата:
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> > Bruce Momjian wrote:
> >> I am seeing the following plpgsql compile failure in CVS:
> 
> > I'm seeing the same thing, and I also have bison 1.75.
> 
> Considering how trivial the grammar change is, it's hard to call this
> anything except a bison bug.  I'd be interested to know what causes it
> though --- is it worth trying to invent a workaround so people don't
> have to upgrade?

Not worth the effort -- email posted requiring 1.85.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073