Re: Going for "all green" buildfarm results

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Mark Wong wrote:
>> Flex is 2.5.33 on both systems. I'm assuming that's too modern so
>> I'll go ahead and stop building 7.3 for those systems.

> You could be lucky the others build. I believe our supported version is
> still 2.5.4, which is what all my linux systems have.

I checked into this and it seems that what we'd need to do is backport
some subset of these 7.4 changes:

2003-09-13 22:18 tgl

* contrib/seg/: Makefile, README.seg, seg.c, seg.sql.in,
segparse.y, segscan.l, expected/seg.out: Make contrib/seg work with
flex 2.5.31. Fix it up to have a real btree operator class, too,
since in PG 7.4 you can't GROUP without one.

2003-09-13 21:52 tgl

* contrib/cube/: Makefile, README.cube, cube.c, cube.sql.in,
cubeparse.y, cubescan.l, expected/cube.out: Make contrib/cube work
with flex 2.5.31. Fix it up to have a real btree operator class,
too, since in PG 7.4 you can't GROUP without one.

2003-09-14 14:44 tgl

* contrib/: tsearch/parser.l, tsearch2/wordparser/parser.l:
Persuade tsearch/tsearch2 to work (or at least pass their
regression tests) when using flex 2.5.31. The fix is to *not* try
to use palloc and pfree for allocations within the lexer; when you
do that, the yy_buffer_stack gets freed at inopportune times. The
code is already set up to do manual deallocation, so I see no
particular advantage to using palloc anyway.

This is probably not worth doing. We're really only maintaining 7.3 for
legacy platforms (the only one I care about is RHEL3 ;-)) and a legacy
platform is likely to have an old flex. It's a tad annoying to lose
buildfarm coverage on it though ...

regards, tom lane