Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, May 9, 2015 at 1:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> For these reasons, I think that if an FDW tried to be laxer than "tables
>> must be on the same pg_foreign_server entry to be joined", the odds
>> approach unity that it would be broken, and probably dangerously broken.
>> So we should just make that check for the FDWs. Anybody who thinks
>> they're smarter than the average bear can use set_join_pathlist_hook,
>> but they are probably wrong.
> Drilling down into postgres_fdw's connection properties seems pretty
> silly; the user isn't likely to create two SERVER objects that are
> identical and then choose which one to use at random, and if they do,
> they deserve what they get. The universe of FDWs, however, is
> potentially bigger than that. What does a server even mean for
> file_fdw, for example?
Nothing, which is why you'd only ever create one per database, and so the
issue doesn't arise anyway. It would only be sane to create multiple
servers per FDW if there were a meaningful difference between them.
In any case, since the existing code doesn't support "remote" joins
involving a local table unless you use the join-path hook, this argument
seems pretty academic. If we tighten the test to be same-server, we will
benefit all but very weirdly designed FDWs. Anybody who's not happy with
that can still use the hook (and I continue to maintain that they will
probably have subtle bugs, but whatever).
Another point worth making is that the coding I have in mind doesn't
really do anything with RelOptInfo.serverid except compare it for
equality. So an FDW that wants to consider some servers interchangeable
for joining purposes could override the value at GetForeignPaths time
(ie replace "serverid" with the OID of a preferred server), and then it
would get GetForeignJoinPaths calls as desired.
regards, tom lane