Re: [PATCHES] [HACKERS] v7.2.4 bundled ...
On Thu, 2003-01-30 at 21:30, Kevin Brown wrote: > > That said, if the parser's gram.y file is anything to go by, the fixes > to make it work with bison 1.75 are trivial, so if you change your > mind I'll be happy to do the work. > If your gung ho about doing the work, I see no reason not to do it and post it to patches or someplace else (gborg?). That way if someone comes along and complains they can't compile it with a new bison, we can always say "Kevin Brown made a patch for that, you can get it at XXX". Robert Treat ---(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
Re: [PATCHES] [HACKERS] v7.2.4 bundled ...
Tom Lane wrote: > Kevin Brown <[EMAIL PROTECTED]> writes: > >> 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? > > What for? If you've bought the assumption that we aren't going to port > 7.2's grammar forward indefinitely, why shouldn't we say it stops with > bison 1.35 rather than 1.75? 1.75 and later are not widely deployed > anyway, as yet. Okay, fair enough. I'll take your word for this (no idea how to determine how widely bison 1.75 and later are deployed). > But the more compelling point is *it does not matter* > to our customers, and only barely to us. No one but a very few > developers will ever again build the .y output files for 7.2.* (even > assuming that there are more 7.2.* releases, which I doubt). Doesn't > seem worth expending any effort on, to me. We have other, more > productive things to do ... Agreed. I wasn't aware, previously, that our source distributions shipped with .c files generated from the .y files. That said, if the parser's gram.y file is anything to go by, the fixes to make it work with bison 1.75 are trivial, so if you change your mind I'll be happy to do the work. -- 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
Re: [PATCHES] [HACKERS] v7.2.4 bundled ...
Kevin Brown <[EMAIL PROTECTED]> writes: >> 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? What for? If you've bought the assumption that we aren't going to port 7.2's grammar forward indefinitely, why shouldn't we say it stops with bison 1.35 rather than 1.75? 1.75 and later are not widely deployed anyway, as yet. But the more compelling point is *it does not matter* to our customers, and only barely to us. No one but a very few developers will ever again build the .y output files for 7.2.* (even assuming that there are more 7.2.* releases, which I doubt). Doesn't seem worth expending any effort on, to me. We have other, more productive things to do ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] v7.2.4 bundled ...
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
