Re: subselects

> > Is that correct?
> 
> Yes, this is right for 6.3. I hope that we'll support subselects in 
> target list, FROM, etc in future.

OK.

> 
> BTW, I'm going to implement subselect in (let's say) "natural" way -
> without substitution of parent query relations into subselect and so on,
> but by execution of (correlated) subqueries for each upper query row
> (may be with cacheing of results in hash table for better performance).
> Sure, this is much more clean way and much more clear how to do this.
> This seems like SQL-func way, but funcs start/run/stop Executor each time
> when called and this breaks performance. 

Sure, lets see how it performs.  Most correlated subqueries are very
slow in commercial databases too.  I guess I thought you could do the
whole subquery, then sort on the correlated columns, which allows quick
access to the results, but if the subquery references only a small part
of the upper query's output, it is quicker to do it your way.

-- 
Bruce Momjian
maillist@candle.pha.pa.us