Erroneous handling of projection for relation already restricted by another relation

[eywalker]

When projecting a relation (call it A) that is restricted by another relation (B), it results incomplete SQL string if B heading contains attributes that are not inside projected attributes of A. For more concrete example, assume that relation A have pk attributes (a, b) and non-pk attributes (x, y, z). Also assume that (x) is a pk attribute in B. Given this, following pseudo-code was giving error:

(A & B).project()

This turns out to be due to recent optimization in Project that expanded the restrictions on the argument of project (in this case A) if there are no aliasing operation during project. This essentially resulted in the restriction (B) to be applied after the projection operation, giving (essentially)

A.project() & B

Note that A.project() only contains (a, b) and not x, thus resulting in improper restriction by B which only contains attribute x.

I believe that this change was introduced in an attempt to speed up some projections where you could truly expand restrictions: for example, if in above case B contained attributes (a,b) instead, then expansion would have worked. However, as this case showed, checking for alias is not enough. I've implemented a compromise where I check for B's heading and see if all attributes of B belongs to projected attributes for A. If true, then restriction is expanded. Otherwise, Subquery is used. It is quite possible that a better optimization can be performed. I just wanted to make sure all were aware of the changes and the reason behind it.

[eywalker]

Current implementation of Project is also still bug laden, as the extra clause I inserted does not work. We will have to carefully visit the implementation and see what performance improvements could be made. We should probably add more tests to verify that we got a perfectly functioning (though possibly slow) version implemented prior to making tweaks.

[dimitri-yatsenko]

I am fixing this on the development branch. Please add a very specific example that reproduces the problem.

[dimitri-yatsenko]

Fixed in e0aadc0?

[dimitri-yatsenko]

Fixed by enclosing restricted relations in subquery. There is certainly a more efficient solution, but this is simple and it works.