>
> I've attached the first two unique-keys patches (v9, 0001, 0002)), your
> patches, but rebased on v9 of unique keys (0003-0006) + a diff patch (0007)
> that applies my suggested changes on top of it.
>
I just realized there's another thing that looks a bit strange too. From reading the thread, I thought it should be the
casethat in create_distinct_paths, it is checked whether the uniqueness in the unique_pathlist matches the uniqueness
thatis needed by the query.
This means that I think what it should be comparing is this:
- The generated index path should have some path-level unique keys set
- The path-level unique keys must be at least as strict as the path-level unique keys. Eg. if path-level is unique on
(a),then query-level must be (a), or possibly (a,b).
I've changed the patch to compare the path-level keys (set in create index path) with the query-level keys in
create_distinct_path.Currently, I don't think the previous implementation was an actual issue leading to incorrect
queries,but it would be causing problems if we tried to extend the uniqueness for distinct to join rels etc.
One question about the unique keys - probably for Andy or David: I've looked in the archives to find arguments
for/againstusing Expr nodes or EquivalenceClasses in the Unique Keys patch. However, I couldn't really find a clear
answerabout why the current patch uses Expr rather than EquivalenceClasses. At some point David mentioned "that
probablyExpr nodes were needed rather than EquivalenceClasses", but it's not really clear to me why. What were the
thoughtsbehind this?
-Floris
