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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Thom Brown <thom(at)linux(dot)com>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Date: 2015-05-08 21:48:25
Message-ID: 23444.1431121705@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-05-08 21:51:27 Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Previous Message Alvaro Herrera 2015-05-08 21:39:41 Re: multixacts woes