> Ah!  That's the trick!  I was playing with unions and gave up because
> I was only trying:
> select a,b union select a,c
> and getting frustrated that the final result wasn't giving me a,b,c but
> was instead putting c values into a b labelled column!
 
Yes, unions are weak that way - the matching isn't on column names, but rather on column positions.  Hence also why some SQL's require ORDER BY 1 rather than ORDER BY custid.
 
> Your example by fudging 0 into the matching col name solves that!
 
Yes, with the often-overlooked fact that a constant (like 0) is allowed in place of field name or expression.  A constant is just a special case of expression.
 
For further edification to everyone here:
 
1.  Though implicit in the solutions I proposed, I should clarify that a GROUP BY clause always occurs together with aggregate functions in the SELECT, and is required when there are such aggregate functions.  Otherwise, the result of SELECT wouldn't be a table equivalent by SQL definition, and it is an SQL requirement that the result of SELECT be a table equivalent.
 
2.  I think I misdescribed HAVING.  I believe HAVING comes right after a GROUP BY clause and is used to include/exclude the aggregate record resulting from the GROUP BY.
 
Man, am I rusty on SQL!