Postgres Pro
Downloads
Home   >   mailing lists

Re: postgres_fdw bug in 9.6 - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: postgres_fdw bug in 9.6
Date
Msg-id CAFjFpRfPdNDBuw4246Y=mFsY_83=5aku8-2ry+0WdHB9BqaWhg@mail.gmail.com
Whole thread Raw
In response to Re: postgres_fdw bug in 9.6  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
Tree view
Probably we should use "could not be created" instead of "was not created" in "... a local path suitable for EPQ checks was not created".

"outer_path should not require relations from inner_path" may be reworded as "outer paths should not be parameterized by the inner relations".

"neither path should require relations from the other path" may be reworded as "neither path should be parameterized by the the other joining relation".


While the comment below mentions ON true, the testcase you have added is for ON
false. Either the testcase should change or this comment. That raises another
question, what happens when somebody does FULL JOIN ON false?
+                     * If special case: for "x FULL JOIN y ON true", there

 FULL JOIN ON FALSE would be handled the same way as FULL JOIN ON TRUE, so I think we should rewrite that comment into something like this: If special case: for "x FULL JOIN y ON true" or "x FULL JOIN y ON false"...

Ok.
 

Why JOIN_RIGHT is being treated differently from JOIN_LEFT? We should be able
to create a nested loop join for JOIN_RIGHT?
+        case JOIN_RIGHT:
+        case JOIN_FULL:

 I don't think so, because nestloop joins aren't supported for JOIN_RIGHT.  See ExecInitNestLoop().

Hmm, I see in match_unsorted_outer()
1254         case JOIN_RIGHT:
1255         case JOIN_FULL:
1256             nestjoinOK = false;
1257             useallclauses = true;
1258             break;

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Statement timeout behavior in extended queries
Next
From: Michael Paquier
Date:
Subject: Letting the client choose the protocol to use during a SASL exchange