Tom Lane wrote: > Kevin Brown <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
