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(at)pcorp(dot)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 involve installing 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