Thread: plpgsql requires bison
I have received a report that pl/plpgsql requires bison to compile. I have verified this is true, at least on BSD/OS 4.01, and since we enable plpgsql compile by default, this requires bison for our standard build. The issue appears to be contents of gram.tab.c, which is part of our distribution, and contains at the top: /* A Bison parser, made from gram.y by GNU Bison version 1.25 */#define YYBISON 1 /* Identify Bison output. */#defineK_ALIAS 258#define K_ASSIGN 259#define K_BEGIN 260#define K_CONSTANT 261#define K_DEBUG 262#define K_DECLARE 263#define K_DEFAULT 264#define K_DOTDOT 265#define K_ELSE 266#define K_END 267 and later on, the contents of gram.y tables. The file appears to allow for the passage of keywords, but is not done by flex/yacc combination. I did:yacc -d gram.ysed -e 's/yy/plpgsql_yy/g' -e 's/YY/PLPGSQL_YY/g' <y.tab.c >pl_gram.csed -e 's/yy/plpgsql_yy/g' -e 's/YY/PLPGSQL_YY/g'<y.tab.h >pl.tab.hrm -f y.tab.c y.tab.h but got errors like:scan.l: In function `plpgsql_yylex':scan.l:85: `K_ASSIGN' undeclared (first use this function)scan.l:85:(Each undeclared identifier is reported only oncescan.l:85: for each function it appears in.)scan.l:87:`K_DOTDOT' undeclared (first use this function)scan.l:88: `K_ALIAS' undeclared (first use this function) Jan, is this a known portability problem? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> I have received a report that pl/plpgsql requires bison to compile. I
> have verified this is true, at least on BSD/OS 4.01, and since we enable
> plpgsql compile by default, this requires bison for our standard build.
This same problem was reported for HPUX a couple weeks ago (see thread
"[PORTS] HP-UX port" on 29 July). I think that moving the #include of
"pl_scan.c" down to the file trailer section, instead of having it in
the file header, would work. Did not try it yet.
regards, tom lane
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > > I have received a report that pl/plpgsql requires bison to compile. I > > have verified this is true, at least on BSD/OS 4.01, and since we enable > > plpgsql compile by default, this requires bison for our standard build. > > This same problem was reported for HPUX a couple weeks ago (see thread > "[PORTS] HP-UX port" on 29 July). I think that moving the #include of > "pl_scan.c" down to the file trailer section, instead of having it in > the file header, would work. Did not try it yet. > > regards, tom lane > > Moving the #include down below the %} does not work. Is there another section. I put it on line 49. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> This same problem was reported for HPUX a couple weeks ago (see thread
>> "[PORTS] HP-UX port" on 29 July). I think that moving the #include of
>> "pl_scan.c" down to the file trailer section, instead of having it in
>> the file header, would work. Did not try it yet.
> Moving the #include down below the %} does not work. Is there another
> section. I put it on line 49.
No, that'd be in the grammar proper. I meant down in the trailing
miscellaneous-C-code section, say right after the %% divider at line
1081. (If I were a yacc expert I'd know the names of these sections,
but I'm just a hacker...)
regards, tom lane
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > >> This same problem was reported for HPUX a couple weeks ago (see thread > >> "[PORTS] HP-UX port" on 29 July). I think that moving the #include of > >> "pl_scan.c" down to the file trailer section, instead of having it in > >> the file header, would work. Did not try it yet. > > > Moving the #include down below the %} does not work. Is there another > > section. I put it on line 49. > > No, that'd be in the grammar proper. I meant down in the trailing > miscellaneous-C-code section, say right after the %% divider at line > 1081. (If I were a yacc expert I'd know the names of these sections, > but I'm just a hacker...) Thank you. That did it. Commit applied. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote:
>
> I have received a report that pl/plpgsql requires bison to compile. I
> have verified this is true, at least on BSD/OS 4.01, and since we enable
> plpgsql compile by default, this requires bison for our standard build.
>
> The issue appears to be contents of gram.tab.c, which is part of our
> distribution, and contains at the top:
>
> [...]
>
> Jan, is this a known portability problem?
I had expected portability problems with the PL/pgSQL parser
and suggested to put prepared flex/bison output files into
our distribution as we do it for the main backend parser.
Unfortunately I forgot about it.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> Bruce Momjian wrote: > > > > > I have received a report that pl/plpgsql requires bison to compile. I > > have verified this is true, at least on BSD/OS 4.01, and since we enable > > plpgsql compile by default, this requires bison for our standard build. > > > > The issue appears to be contents of gram.tab.c, which is part of our > > distribution, and contains at the top: > > > > [...] > > > > Jan, is this a known portability problem? > > I had expected portability problems with the PL/pgSQL parser > and suggested to put prepared flex/bison output files into > our distribution as we do it for the main backend parser. > Unfortunately I forgot about it. OK, I have fixed the problem by testing to see if I am running Bison, and doing the include in the proper place. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026