Re: UNIONS

At 01:07 PM 8/7/2000, Tom Lane wrote:<br /><blockquote cite="cite" type="cite">Thomas Swan <tswan@olemiss.edu>
writes:<br/> > select id, null as text from foo union select id, name from foo_child;<br /> > fails with<br />
>unable to trasform {insert whatever type here} into unknown<br /> >          Each UNION | EXCEPT | INTERSECT
clausemust have compatible target <br /> > types<br /><br /> The UNION type-resolution code could use some work;
rightnow I think<br /> the algorithm is to use the types of the first SELECT and force<br /> everything else into
that. A more symmetrical<br /> promote-to-common-supertype approach would be nice.  The UNION code is<br /> such a mess
thatI haven't wanted to touch it until we do querytree<br /> revisions in 7.2, though.<br /><br /> In the meantime, you
shouldforce the NULL to have the datatype you want<br /> with something like "null::text" or "cast (null as text)". 
Notethat<br /> the way you have it above is only assigning a column label that happens<br /> to be "text"; it's not a
typecoercion.<br /></blockquote><font face="Microsoft Sans Serif"><br /> The reason I was asking is that I had an idea
fordoing the select ** from tablename* that would expand.<br /><br /> It could be macro of sorts but part of it
dependingon creating a null table or the equivalent of it with nothing but a null column for each different column of
theset.  I had  a reverse traversal of the classes set up, but it didn't work because I could allow for all the columns
ofall the children.   <br /><br /> If you could recommend a place to start, I wouldn't mind looking at the existing
codeand seeing what I could do.<br /><br />  - <br /> - <b><u>Thomas Swan</u></b>                                   <br
/>- Graduate Student  - Computer Science<br /> - The University of Mississippi<br /> - <br /> - "People can be
categorizedinto two fundamental <br /> - groups, those that divide people into two groups <br /> - and those that
don't."</font>