Hi, >> Thus the condition should probably be >> else if (selector->ts.type == BT_DERIVED) as the BT_CLASS was handled >> before? OK with that change (if it works). > > Good point. And yes, it works. > > However, on second thought, I wonder why we need to treat the case > "selector->ts.type == BT_DERIVED" at all, since the selector in a > SELECT TYPE statement is required to be polymorphic (which is being > checked later in resolve_select_type). I.e. we weill get an error on > the BT_DERIVED case anyway, so I don't see why we need to build a > class container at all here (the only reason I could imagine would be > something like error recovery). > > The attached new version is what I'm regtesting right now (with the > whole BT_DERIVED branch removed, since it should not be needed). Ok if > it succeeds?
It does regtest cleanly. Ok for trunk and 4.8? Cheers, Janus
