Re: relational tables and objects

> Ok. So query optimization is going to be a matter of letting this function
> decide on the basis of the types what algorithm it is going to use? That's
> not really open-ended (it cannot take new table types into account without
> changing this function) but I don't see a way to do that anyway.

There are two things: tables and table implementations. Each of them is a class template.
Class table is part of RTL. It is parametrized with list of columns, sort_order and used implementation.
There may be more than one table implementation class. RTL algorithms treate them equally.
We think that this approach lets separate concerns placing relational agorithms in RTL layer and
table implementation on another on. We wish to avoid monolitic approach, which theoretically
can be more efficient, but also is not flexible.

Query optimization is not in RTL now. You are right, it will need some additional information (hints).
We have to postpone this work, because of limitations of current C++ compilers.

>
> >Result of this call will be object of class join_t_eq<TableA, TableB,
> >list_of_columns_to_be_equal>.
>
> Interesting. Why is the list of columns in the type? And if I do
> join(A,join(B,C)) will the result have the same type as join(join(A,B),C)
or
> not?

Yes they will have the same type. List of columns let us tell compiler which of join use

SELECT A.a1, A.a2, A.a3, B.b2, B.b3
FROM A, B
WHERE A.a1 = B.b1

or

SELECT A.a1, A.a2, A.a3, B.b3
FROM A, B
WHERE A.a1 = B.b1 AND A.a2 = B.b2

>So can you statically type the set union?

Pardon me, I do not understand the question.

Dm. Arapov Received on Sat Nov 02 2002 - 18:27:55 CET