Re: Is there a way around function search_path killing SQL function inlining?

On 03/08/2016 01:24 AM, Regina Obe wrote:
>>> On Fri, Mar 4, 2016 at 9:29 PM, Regina Obe <lr@pcorp.us>> wrote:
>>> I think the answer to this question is NO, but thought I'd ask.
>>>
>>> A lot of folks in PostGIS land are suffering from restore issues,
>>> materialized view issues etc. because we have functions such as
>>>
>>> ST_Intersects
>>>
>>> Which does _ST_Intersects  AND &&
>>>
>>> Since _ST_Intersects is not schema qualified, during database restore
>>> (which sets the schema to the table or view schema), materialized
>>> views that depend on this do not come back.
>
>> Could you provide a self-contained, reproducible test case that illustrates this problem?  Ideally, one that doesn't
involveinstalling PostGIS?
 
>
> Here is a script just involving the built in geometric types that has the same issue:

Hi,

I think Robert was asking for a test case for the database restore problems.

The reason your no_inline() function cannot be inlined is due to lack of 
support of inlining of any functions which have any config variable set, 
not matter which. The search_path does not get any special treatment, 
and I am not sure if it could in the general case since the new search 
path will apply too to functions called by the function which changed 
the search path.

Andreas