From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [SQL] Re: [HACKERS] Counting bool flags in a complex query |
Date: | 1999-07-20 15:29:32 |
Message-ID: | 29691.932484572@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
>> We've got a few bugs to fix here :-(
> Tom, can you give me a list for the TODO list?
The two cases I mentioned yesterday can be summarized as
* SELECT ... UNION ... ORDER BY fails when sort expr not in result list
* INSERT ... SELECT ... UNION is not reliable
Another thing I realized last night is that Except_Intersect_Rewrite's
coercion of all the sub-select target lists to compatible types is
poorly done; for example in the regression database
regression=> select f1 from int4_tbl union select q1 from int8_tbl;
ERROR: int8 conversion to int4 is out of range
I think we want to use logic similar to what exists for CASE expressions
to find the common supertype of the sub-select results and coerce all
the sub-selects to that type. (Thomas, any comments here? Can we pull
the CASE logic out of transformExpr and make it into a utility routine?)
* Be smarter about promoting types when UNION merges different data types
Finally, heaven help you if you have a GROUP BY in one of the subselects
whose column gets coerced to a different type by Except_Intersect_Rewrite,
because the sortop for the GROUP BY has already been assigned.
(This is another situation where a multi-level output representation
would be a better answer...)
* SELECT ... UNION ... GROUP BY fails if column types disagree
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ansley, Michael | 1999-07-20 15:30:04 | RE: [HACKERS] psql & query string length |
Previous Message | Thomas Lockhart | 1999-07-20 15:21:45 | Re: [PORTS] RedHat6.0 & Alpha |