Tom Lane wrote:
> Kevin Brown <kevin@sysexperts.com> writes:
> > I'm attaching a patch for 7.2.4's parser/gram.y that fixes all of
> > bison 1.75's complaints.
>
> But parser/gram.y is not the only .y file in the distribution. To call
> ourselves 1.75-safe, we'd have to go through this same exercise for
> all of 'em:
>
> $ find REL7_2 -name '*.y'
> REL7_2/pgsql/contrib/cube/cubeparse.y
> REL7_2/pgsql/contrib/seg/segparse.y
> REL7_2/pgsql/src/backend/bootstrap/bootparse.y
> REL7_2/pgsql/src/backend/parser/gram.y
> REL7_2/pgsql/src/interfaces/ecpg/preproc/preproc.y
> REL7_2/pgsql/src/pl/plpgsql/src/gram.y
> $
I'll be happy to go through the same process for those files.
> And on top of that, 1.75 isn't the current bison release anymore; the
> one that is current has changed the spelling of syntax error messages,
> which means that the regression tests will fail (and perhaps clients
> that are looking for syntax errors, too). We have agreed how to fix
> this in HEAD, but not actually done it yet --- shall we put that
> not-even-written-let-alone-tested code into 7.2.4 as well?
I assume you're referring to the use of error numbers here. Yes, I
agree that *that* code shouldn't go into 7.2.4.
> I think it's best to leave well enough alone. The tarball ships with
> working bison output files anyway, so all of this really only matters
> to people trying to build 7.2.* from a CVS pull.
Okay, fair enough, but if we intend to continue to maintain 7.2.*,
shouldn't we at least fix the .y files? We can hack configure to fail
if it detects a bison later than 1.75, or we can simply put something
in the release notes that says if the regressions fail on error
detection it may mean that an incompatible bison was used.
--
Kevin Brown kevin@sysexperts.com