>>>
>>> Another issue is that at the point when this code is called, we do not
>>> know yet if the full outer join can be changed to left, right or inner
>>> join.
> After investigating, I found that this is the root of the issue regarding the
> NATURAL FULL -> RIGHT rewrite results being wrong. We mark the common fields
> between t1 and t2 from the set of fields present in the left neighbor table
> (assuming that we can rewrite the natural join as a left join). Later,
> during insert_fields, those common fields see values only from the left
> table. Values that should be in the result from the right table are skipped
> because their corresponding fields were not included. There are a lot of
> mechanics I’m skipping here regarding name resolution contexts, but that’s
> the general idea. Concerning solutions: it’s not so easy to remember both
> sets of “common fields” (one pertaining to the left table and another to the
> right table) and just use the correct one because insert_fields is before we
> attempt to rewrite FULL JOINs (insert_fields is called during the prepare
> phase while rewriting JOINs is done during the optimization phase).
Yes, I agree that this is where we can use COALESCE(), applying it to each pair
of common fields from the tables.
_______________________________________________
developers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
