> > 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