Hi Mikael, thanks for the review!
>> + else if (selector->ts.u.derived) > > Hum, accessing ts.u.derived is correct only if selector->ts.type is > BT_DERIVED or BT_CLASS, isn't it? yes. > 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? Cheers, Janus
pr58185_v3.diff
Description: Binary data
