On Thu, Sep 3, 2015 at 11:51 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Sep 2, 2015 at 1:47 PM, Tom Lane <t...@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_tx4...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
