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

From Tom Lane
Subject Re: Is there a way around function search_path killing SQL function inlining?
Date
Msg-id 18542.1470845263@sss.pgh.pa.us
Whole thread Raw
In response to Re: Is there a way around function search_path killing SQL function inlining?  (Michael Banck <michael.banck@credativ.de>)
Responses Re: Is there a way around function search_path killing SQL function inlining?  ("Regina Obe" <lr@pcorp.us>)
List pgsql-hackers
Michael Banck <michael.banck@credativ.de> writes:
> 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.

It's not simply a matter of allowing the substitution to occur while
reading the extension script.  "Relocatable" means that we support
ALTER EXTENSION SET SCHEMA, which means moving all the extension's objects
into some new schema.  There's no good way to run around and find places
where @extschema@ was replaced in order to change them to something else.

Basically the point of @extschema@ is to support extensions that are
relocatable at installation time, but not afterwards.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Slowness of extended protocol
Next
From: Vladimir Sitnikov
Date:
Subject: Re: Slowness of extended protocol