Robert Haas <robertmh...@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 <t...@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 that applied to the
join. The check on restrictlist == NIL is really unnecessary anyway,
because select_mergejoin_clauses already checked for and complained
about any unmergejoinable join clauses. So just take it out.
is preferable to something like
Author: Tom Lane <t...@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 that applied to the
join. The check on restrictlist == NIL is really unnecessary anyway,
because select_mergejoin_clauses already 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
