Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat

On Mon, Mar 14, 2016 at 8:21 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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