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

From Robert Haas
Subject Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat
Date
Msg-id CA+TgmoZaiM80TJySOhk6DR3fqHbZEELTuyVboL6MOtvFqKmJ6w@mail.gmail.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat
List pgsql-hackers
On Sun, Mar 13, 2016 at 10:51 PM, 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?
>
> 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.

I think we should just fix build_simple_rel() so that it doesn't fail
if there is no user mapping.  It can just set rel->umid to InvalidOid
in that case, and if necessary we can adjust the code elsewhere to
tolerate that.  This wasn't an intentional behavior change, and I
think we should just put things back to the way they were.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check
Next
From: Anastasia Lubennikova
Date:
Subject: Re: WIP: Covering + unique indexes.