Re: [PORTS] plpgsql & bsdi 4.0

> >> Any suggestions? Thanks in advance...
> >
> >6.5.2 should have allowed you to use either bison or yacc. I am running
> >bsdi 4.0, but have never fooled around with plpgsql.
> >
>
> Thanks for chiming in...
>
> It otherwise seems to do fine (at least on the regression
> tests), but it does fail the plpgsql regression test, and I need plpgsql.
>
> I'm startled that you think that either bison or yacc would work.
> Out of the box, every plpgsql invocation fails (and thus everything in
> the plpgsql regression test) with the unresolved symbol error.
>
> Does a virgin 6.5.2 install pass the plpgsql regression test on your
> 4.0 bsdi box? Thanks.
>

OK, I see it now:

ERROR: Load of file /u/pg/lib/plpgsql.so failed: Unable to resolve symbol
./bin/postmaster: can't resolve symbol 'plpgsql_yylineno'

Not sure about the cause. I see the several references to that variable
as extern, but no non-extern references. Does BSDI handle this
differently than other OS's? If a library has no non-external
definition of a variable, a reference to the shared library would cause
such an error as above, right?

I am attaching a patch which defines plpgsql_yylineno as non-extern in
one of the files. I am applying this to the current source tree too.
That seems to fix most of the problems on bsdi. I see in the regression
tests some strange stuff like:

QUERY: select * from PField_v1 where pfname = 'PF0_1' order by slotname;
NOTICE: plpgsql: ERROR during compile of wslot_slotlink_view near line 1
ERROR: parse error at or near "qR^F"

Not sure what is causing that. My guess is that the there is still a
problem with the parser internals referenced by plpgsql on bsdi. Please
try my patch, and let me know if it improves things.

Jan, any ideas?

--
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