2015-05-09 6:48 GMT+09:00 Tom Lane <t...@sss.pgh.pa.us>: > ... btw, I just noticed something that had escaped me because it seems so > obviously wrong that I had not even stopped to consider the possibility > that the code was doing what it's doing. To wit, that the planner > supposes that two foreign tables are potentially remote-joinable if they > share the same underlying FDW handler function. Not the same server, and > not even the same pg_foreign_data_wrapper entry, but the pg_proc entry for > the handler function. I think this is fundamentally bogus. Under what > circumstances are we not just laying off the need to check same server > origin onto the FDW? How is it that the urgent need for the FDW to check > for that isn't even mentioned in the documentation? > Indeed. Comparison of fdw_handler may cause unexpected behavior. I agree it needs to be fixed up.
> I think that we'd really be better off insisting on same server (as in > same pg_foreign_server OID), hence automatically same FDW, and what's > even more important, same user mapping for any possible query execution > context. The possibility that there are some corner cases where some FDWs > could optimize other scenarios seems to me to be poor return for the bugs > and security holes that will arise any time typical FDWs forget to check > this. > The former version of foreign/custom-join patch did check for joinable relations using FDW server id, however, it was changed to the current form because it may have additional optimization opportunity - in case when multiple foreign servers have same remote host, access credential and others... Also, I understand your concern about potential security holes by oversight. It is an issue like a weighing scales, however, it seems to me the benefit come from the potential optimization case does not negate the security- hole risk enough. So, I'll make a patch to change the logic to check joinable foreign-tables. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers