On Mon, Mar 14, 2016 at 8:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes: > On 2016/03/13 4:46, Andres Freund wrote: >> ... The difference apears to be the >> check that's now in build_simple_rel() - there was nothing hitting the >> user mapping code before for file_fdw.
> Exactly.
> I'm not sure it's worth complicating the code to keep that behavior, so > I'd vote for adding the change notice to 9.6 release notes or something > like that in addition to updating file-fdw.sgml.
Perhaps it would be useful for an FDW to be able to specify that user mappings are meaningless to it? And then bypass this check for such FDWs?
In such a case, whether FDWs be given chance to push down joins? I guess the answer is yes, but wanted to confirm.
I'm not really sold on enforcing that people create meaningless user mappings. For one thing, they're likely to be sloppy about it, which could lead to latent security problems if the FDW later acquires a concept that user mappings mean something.
Hmm. Should we let FDW handler set a boolean in fdwroutine specifying whether the core code should bother about user mapping or not. This way the author of FDW decides whether s/he is going to write code that uses user mappings or not. A small problem with that is PG documentation describes fdwroutine as a structure holding function pointers and now it will store a boolean variable. But I think that can be managed either by having this option as a function pointer returning boolean or changing the documentation.
Other problem is what should we do when a user creates or has an existing user mapping for an FDW which specifies that user mapping is meaningless to it. Should we allow the user mapping to be created but ignore it or do not allow it to be created? In the later case, what should happen to the existing user mappings?
--
Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
