First I think it is important to nail down the interpretation of how we know when to (1) restrict the hierarchy in the SQL FROM clause versus (2) restrict the hierarchy local to the SQL predicate (make it a CONJUNCTION /AND )
IMO this distinction boils down the SQM concept of a from-element's "intrinsic subclass indicator". From there we can look at A from-element whose "intrinsic subclass indicator" is one of its subclasses would render the restriction into the SQL FROM clause (use of inner join, adding restrictive join predicate).
We'd just need to nail down situations and whether they that indicate "flipping" the from-element's "intrinsic subclass indicator" . IMO this is as follows generically :
# Certainly use of the TREAT in the FROM element clause defines the "intrinsic subclass indicator" of the generated TREATed from-element
# I'd argue that the use of TREAT in any other clause used in a predicate ( the main thing with predicates is that they could be part of a DISJUNCTION/OR branch which means the restriction WHERE and HAVING clauses would need to be indicate using predicate- local to restrictions *unless* the predicate by composing a CONJUNCTION/AND predicate grouping source from-element already indicates an "intrinsic subclass indicator" in which case we'd rely on the original predicate plus the restrictive predicate). "intrinsic subclass indicator" handling
# # That means I'd also argue that use of TREAT in the SELECT, WHERE, GROUP BY and ORDER BY clauses would inherently indicate an "intrinsic subclass indicator" for the TREATed from-element. "intrinsic subclass indicator" can also be made more resitrictive restrictive (in terms of more conrete concrete subclass) throughout these clauses
## Use of TREAT in the WHERE and HAVING clauses would indicate using predicate (i.e. SELECT names an "intermediate subclass", but ORDER BY indicates a "leaf subclass" - local resitrictions *unles* we'd apply the source "leaf" as the from-element already indicates an 's "intrinsic subclass indicator".
## we need to decide whether a CASE statement falls into the predicate-local case or the "intrinsic subclass indicator" case. Most likely being inside of a CASE should not trigger flipping the "intrinsic subclass indicator".
Look at Christian's examples and assertions (the link GitHub project) to see how they stack up with that generalizable algorithm. |
|
