Robert Haas <robertmhaas@gmail.com> writes:
> But I still want an option for the original behavior. I have been
> using it extensively and I like it.
You really think this:
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [872c1497f] 2005-05-24 18:02:31 +0000
Branch: REL9_0_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
Branch: REL8_4_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
Branch: REL8_3_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
Branch: REL8_2_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
Branch: REL8_1_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
Branch: REL8_0_STABLE [a94ace079] 2005-05-24 18:02:55 +0000
Branch: REL7_4_STABLE [0a7b3a364] 2005-05-24 18:03:24 +0000
Previous fix for "x FULL JOIN y ON true" failed to handle the case where there was also a WHERE-clause restriction
thatapplied to the join. The check on restrictlist == NIL is really unnecessary anyway, because
select_mergejoin_clausesalready checked for and complained about any unmergejoinable join clauses. So just take it
out.
is preferable to something like
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL8_1 [872c1497f] 2005-05-24 18:02:31 +0000
Branch: REL8_0_STABLE Release: REL8_0_4 [a94ace079] 2005-05-24 18:02:55 +0000
Branch: REL7_4_STABLE Release: REL7_4_9 [0a7b3a364] 2005-05-24 18:03:24 +0000
Previous fix for "x FULL JOIN y ON true" failed to handle the case where there was also a WHERE-clause restriction
thatapplied to the join. The check on restrictlist == NIL is really unnecessary anyway, because
select_mergejoin_clausesalready checked for and complained about any unmergejoinable join clauses. So just take it
out.
? It's not hard to offer an option for that, I guess, but I foresee an
argument about what the default is going to be.
regards, tom lane