> Good. I assume UNION NULL is still an issue one of us needs to fix.
OK, I just committed changes to parse_clause.c which fix the most
obvious "UNION SELECT NULL" problems:
postgres=> select 1 union select null;
?column?
--------
1
(2 rows)
Other permutations work too. The code also gets the types right if there
are multiple UNION clauses (remember the type of the result should be
the same as the type of the first clause in the UNION):
postgres=> select 1.1 as "float" union select NULL
postgres-> union select 2 union select 3.3;
float
-----
1.1 <--- (this value determined the types)
2 <--- (this was an int after a null)
3.3 <--- (this double came after an int)
<--- (null is here)
(4 rows)
In testing I found at least one remaining case with problems. It
involves a UNION ALL in clauses other than the first:
postgres=> select 1 union select 2 union all select null;
Backend message type 0x44 arrived while idle
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally before or while
processing the request.
We have lost the connection to the backend, so further processing is
impossible. Terminating.
At the same time, the backend printed the following:
Too Large Allocation Request("!(0 < (size)
&& (size) <= (0xfffffff)):size=-2 [0xfffffffe]",
File: "mcxt.c", Line: 228)
!(0 < (size) && (size) <= (0xfffffff)) (0)
Do you want to look at this Bruce? I haven't looked at it yet, but think
it might be deeper into the backend than the parser (haven't run into
mcxt.c before).
I am testing on a Friday's version of the cvs tree.
- Tom