On Thu, Sep 3, 2015 at 11:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Sep 2, 2015 at 1:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Offhand I think that the
>>> most likely way to build that text will be to examine the query's jointree
>>> to see where c,d,e appear in it. But in any case, that's a separate issue
>>> and I fail to see how plopping the join search problem into the FDW's lap
>>> would make it any easier.
>
>> Yeah, I am not advocating for putting the hook in
>> standard_join_search. I'm explaining why I put it in
>> add_paths_to_joinrel instead of, as I believe you were advocating, in
>> make_join_rel prior to the big switch.
>
> If you had a solution to the how-to-build-the-query-text problem,
> and it depended on that hook placement, then your argument might
> make some sense. As is, you've entirely failed to convince me
> that this placement is not wrong, wasteful, and likely to create
> unnecessary API breaks for FDWs.
>
> (Also, per my last message on the subject, *after* the switch
> is what I think makes sense.)
After re-reading a few emails, I've realized that I've let myself get
a bit confused here and have unwittingly switched sides in this
argument. <puts brown paper bag over head>
When we originally discussed this back in April, I was arguing for
either make_join_rel() or add_paths_to_joinrel() and you were arguing
for standard_join_search(). See here:
http://www.postgresql.org/message-id/CA+TgmobOADxTbsCt-j+dDVefWGK1WxY4p8AVDp1Pz48_TX4XTA@mail.gmail.com
I thought we were still having the same argument, but we're not.
You're now arguing for make_one_rel(), which back then was perfectly
acceptable to me, and now that I've gotten by thinking un-fuzzed,
really still is, except for the question posed in the closing
paragraph of that email, which is (mostly) whether clients like
postgres_fdw are going to need extra_lateral_rels in order to do the
right thing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
