Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Zdenek Kotala wrote: >> What do you mean "not very portable"? What could be problem there? > I'm not sure. My point is that it seems your parse.h requires > TYPE_IS_DECLARED, but mine doesn't. What else could be lurking in there > that requires a specific fix? The "portability" axis of concern here is portability across different versions of bison. ATM I believe we work with everything from 1.875 up, and I'd be loath to give that up. I concur with Alvaro that this feels like a kluge rather than a permanent solution. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes: > TYPE_IS_DECLARED was my mistake. It should be YYSTYPE_IS_DECLARED. It > works because YYSTYPE is also defined and #ifdef checks both. Copy and > paste :( error. Sorry for confusion. I'm going to send new version. [ after further review... ] It looks to me like the intended use of YYSTYPE_IS_DECLARED is to denote the case where the user has supplied a typedef, not macro, definition of YYSTYPE. So defining YYSTYPE as a macro and setting YYSTYPE_IS_DECLARED as well really seems incorrect. The real question with all this is that while the Bison manual clearly says that you can #define YYSTYPE, there is not anything suggesting that you can or should do that when using %union; they are presented as two different ways of defining the type. So I find it a bit surprising that the #if is there at all in parse.h. Nonetheless it is there in all versions from 1.875 to 2.3, and in the 2.3 manual it says Unless `YYSTYPE' is already defined as a macro, the output header declares `YYSTYPE'. So apparently the Bison guys do intend to carry that behavior forward. AFAICT, therefore, the proposed patch should only define YYSTYPE and not anything else (there's no need to be afraid of YYLTYPE at present). regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Huh, I think the point is to be able to build 8.3 at all on certain > Solaris releases. I think it qualifies as a portability fix. (a) it wasn't "to build at all", it was to allow "inline" to be enabled on Sun Studio's compiler, which apparently is too dumb to not generate copies of an unreferenced inline function. (b) portability fix or not, this ain't going into 8.3. It's *far* too invasive for this late stage of the cycle. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match