You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We generally try to assign unique aliases to tables in the SQL tree. However, in some cases we do reuse the same alias; this occurs in non-conflicting contexts, i.e. where there's no scope overlap between the two contexts. So there's no functional impact at the moment as far as we know (though there may be databases out there which could have a problem with this); it's still a good idea to keep aliases as unique as possible for readability, at the very least.
The text was updated successfully, but these errors were encountered:
Note: this will likely never fully go away... Once source of duplicate table aliases is when we clone a tree fragment and then reintegrate the result back into the tree (i.e. GroupBy). But another is e.g. null semantics processor which also adds compensation clauses, causing the same instance to get referenced multiple times in the tree (this is also not great for perf, of course).
We generally try to assign unique aliases to tables in the SQL tree. However, in some cases we do reuse the same alias; this occurs in non-conflicting contexts, i.e. where there's no scope overlap between the two contexts. So there's no functional impact at the moment as far as we know (though there may be databases out there which could have a problem with this); it's still a good idea to keep aliases as unique as possible for readability, at the very least.
The text was updated successfully, but these errors were encountered: