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:
Tue, 25 Mar 2003 00:43:35 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
plpgsql compile failure
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


Mon, 24 Mar 2003 21:49:57 -0800
Joe Conway <mail@joeconway.com>
Re: plpgsql compile failure
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


Tue, 25 Mar 2003 09:30:34 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: plpgsql compile failure 
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, Pennsylvania 19073


Tue, 25 Mar 2003 10:04:29 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: plpgsql compile failure