> I looked briefly at whether we could improve that situation. > Two of the four uses of ECPGColLabelCommon in ecpg.trailer can be > converted to the more general ECPGColLabel without difficulty, > but trying to change either of the uses in var_type results in > literally thousands of shift/reduce and reduce/reduce conflicts. > This seems to be because what follows ecpgstart can be either a general > SQL statement or an ECPGVarDeclaration (beginning with var_type), > and bison isn't smart enough to disambiguate. I have a feeling that > this situation could be improved with enough elbow grease, because > plpgsql manages to solve a closely-related problem in allowing its > assignment statements to coexist with general SQL statements. But > I don't have the interest to tackle it personally, and anyway any > fix would probably be more invasive than we want to put in post-beta.
Right, the reason for all this is that the part after the "exec sql" could be either language, SQL or C. It has been like this for all those years. I do not claim that the solution we have is the best, it's only the best I could come up with when I implemented it. If anyone has a better way, please be my guest. > I also wondered briefly about just changing the affected test cases, > reasoning that breaking some ECPG applications that use "string" is > less bad than breaking everybody else that uses "string". But type > "string" is apparently a standard ECPG and/or INFORMIX thing, so we > probably can't get away with that. IIRC STRING is a normal datatype for INFORMIX and thus is implemented in ECPG for its compatibility. > Hence, I propose the attached, which fixes the easily-fixable > ECPGColLabelCommon uses and adds a hard-wired special case for > STRING to handle the var_type usage. I'm fine with this approach. Thanks Tom. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org
