Re: Oddity in handling of cached plans for FDW queries - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: Oddity in handling of cached plans for FDW queries
Date
Msg-id 9b21f8e3-13c7-5b9a-7f35-edddef21c181@lab.ntt.co.jp
Whole thread Raw
In response to Re: Oddity in handling of cached plans for FDW queries  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Oddity in handling of cached plans for FDW queries  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
On 2016/07/16 6:25, Tom Lane wrote:
> Pushed, after fooling around with it some more so that it would cover the
> case we discussed where the join could be allowed if we restrict the plan
> to be executed by the owner of a view used in the query.

I left that for future work, but I'm happy to have that in 9.6.  Thanks  
for improving and committing the patch!

One thing I'd like to discuss is GetUserMappingById/GetUserMappingId.  
Though those functions aren't used in any places, I didn't take them  
out, because I thought somebody else would need them someday.  But  
considering that user mapping OIDs now aren't available in RelOptInfos,  
at least the former might be rather useless.  Should we keep them in core?

Best regards,
Etsuro Fujita





pgsql-hackers by date:

Previous
From: Satoshi Nagayasu
Date:
Subject: Re: DROP OWNED BY ... CACADE & "could not open relation with OID" error
Next
From: Amit Kapila
Date:
Subject: Re: PoC: Make it possible to disallow WHERE-less UPDATE and DELETE