Re: Is there a way around function search_path killing SQL function inlining? - Mailing list pgsql-hackers

From Michael Banck
Subject Re: Is there a way around function search_path killing SQL function inlining?
Date
Msg-id 20160810155411.GA5488@nighthawk.caipicrew.dd-dns.de
Whole thread Raw
In response to Re: Is there a way around function search_path killing SQL function inlining?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Is there a way around function search_path killing SQL function inlining?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Mar 10, 2016 at 11:48:41AM -0500, Tom Lane wrote:
> If you're worried about preserving relocatability of an extension
> containing such functions, the @extschema@ feature might help.

As I've been bitten by this problem recently, I thought I'd take a look
at editing the PostGIS extension SQL file to this end, but contrary to
the above, the @extschema@ feature only applies to non-relocatable
extensions, from src/backend/commands/extension.c:
 * If it's not relocatable, substitute the target schema name for * occurrences of @extschema@. * * For a relocatable
extension,we needn't do this.  There cannot be * any need for @extschema@, else it wouldn't be relocatable.
 

I'm not sure that logic is sound - even if setting @extschema@ 
explicitly in the SQL functions bodies kills inlining (not sure about
that) or wouldn't help for other reasons, ISTM this should be 
reconsidered in the light of the use case with materialized views during
restore.


Best regards,

Michael

-- 
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax:  +49 2166 9901-100
Email: michael.banck@credativ.de

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer



pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Proposal for CSN based snapshots
Next
From: Robert Haas
Date:
Subject: Re: Slowness of extended protocol