Re: UNIONS
Thomas Swan <tswan@olemiss.edu>
From: Thomas Swan <tswan@olemiss.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2000-08-07T18:56:31Z
Lists: pgsql-hackers
At 01:07 PM 8/7/2000, Tom Lane wrote:
>Thomas Swan <tswan@olemiss.edu> writes:
> > select id, null as text from foo union select id, name from foo_child;
> > fails with
> > unable to trasform {insert whatever type here} into unknown
> > Each UNION | EXCEPT | INTERSECT clause must have compatible
> target
> > types
>
>The UNION type-resolution code could use some work; right now I think
>the algorithm is to use the types of the first SELECT and force
>everything else into that. A more symmetrical
>promote-to-common-supertype approach would be nice. The UNION code is
>such a mess that I haven't wanted to touch it until we do querytree
>revisions in 7.2, though.
>
>In the meantime, you should force the NULL to have the datatype you want
>with something like "null::text" or "cast (null as text)". Note that
>the way you have it above is only assigning a column label that happens
>to be "text"; it's not a type coercion.
The reason I was asking is that I had an idea for doing the select ** from
tablename* that would expand.
It could be macro of sorts but part of it depending on creating a null
table or the equivalent of it with nothing but a null column for each
different column of the set. I had a reverse traversal of the classes set
up, but it didn't work because I could allow for all the columns of all the
children.
If you could recommend a place to start, I wouldn't mind looking at the
existing code and seeing what I could do.
-
- Thomas Swan
- Graduate Student - Computer Science
- The University of Mississippi
-
- "People can be categorized into two fundamental
- groups, those that divide people into two groups
- and those that don't."