Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Date
Msg-id 23444.1431121705@sss.pgh.pa.us
Whole thread Raw
In response to Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
... 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?

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: multixacts woes
Next
From: Tom Lane
Date:
Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0