Re: creating extension including dependencies

On 2015-07-19 17:16, Michael Paquier wrote:
> On Sat, Jul 18, 2015 at 8:00 AM, Petr Jelinek <petr@2ndquadrant.com> wrote:
>> On 2015-07-15 06:07, Michael Paquier wrote:
>>>
>>> On Fri, Jul 10, 2015 at 11:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>>
>>>> Andres Freund <andres@anarazel.de> writes:
>>>>>
>>>>> On July 10, 2015 4:16:59 PM GMT+02:00, Tom Lane <tgl@sss.pgh.pa.us>
>>>>> wrote:
>>>>>>
>>>>>> Would that propagate down through multiple levels of CASCADE?
>>>>>> (Although
>>>>>> I'm not sure it would be sensible for a non-relocatable extension to
>>>>>> depend on a relocatable one, so maybe the need doesn't arise in
>>>>>> practice.)
>>>>
>>>>
>>>>> I'd day so. I was thinking it'd adding a flag that allows to pass a
>>>>> schema to a non relocatable extension. That'd then be passed down. I
>>>>> agree that it's unlikely to be used often.
>>>>
>>>>
>>>> Yeah, I was visualizing it slightly differently, as a separate
>>>> internal-only option "schema_if_needed", but it works out to the
>>>> same thing either way.
>>
>>
>> I added DEFAULT SCHEMA option into CREATE EXTENSION which behaves like
>> SCHEMA but only for extension that don't specify their schema and is
>> mutually exclusive with just SCHEMA. The DEFAULT SCHEMA propagates when
>> CASCADE is used while the SCHEMA option does not propagate. I'd like to hear
>> opinions about this behavior. It would be possible to propagate SCHEMA as
>> DEFAULT SCHEMA but that might have surprising results (installing
>> dependencies in same schema as the current ext).
>
> Hm...
>
> First, the current patch has a surprising behavior because it fails to
> create an extension in cascade when creation is attempted on a custom
> schema:
> =# create schema po;
> CREATE SCHEMA
> =# create extension hstore_plperl with schema po cascade;
> NOTICE:  00000: installing required extension "hstore"
> LOCATION:  CreateExtension, extension.c:1483
> NOTICE:  00000: installing required extension "plperl"
> LOCATION:  CreateExtension, extension.c:1483
> ERROR:  42704: type "hstore" does not exist
> LOCATION:  typenameType, parse_type.c:258
> Time: 30.071 ms
> To facilitate the life of users, I think that the parent extensions
> should be created on the same schema as its child by default. In this
> case hstore should be created in po, not public.
>

That's actually a bug because the previous version of the patch did not
set the reqext correctly after creating the required extension.

>
> Hence, as a schema can only be specified in a control file for a
> non-relocatable extension, I think that the schema name propagated to
> the root extensions should be the one specified in the control file of
> the child if it is defined in it instead of the one specified by user
> (imagine for example an extension created in cascade that requires
> adminpack, extension that can only be deployed in pg_catalog), and
> have the root node use its own schema if it has one in its control
> file by default.
>
> For example in this case:
> foo1 (WITH SCHEMA hoge) -----> foo2 (schema = pg_catalog) -----> foo2_1
>                                                  |
>                                  |--> foo2_2
>                                                  ---> foo3 (no schema)
> With this command:
> CREATE EXTENSION foo1 WITH SCHEMA hoge;
> foo3 is created on schema po. foo2, as well its required dependencies
> foo2_1 and foo2_2 are created on pg_catalog.
>
> Now DEFAULT SCHEMA is trying to achieve: "Hey, I want to define foo2_1
> and foo2_2 on schema hoge". This may be worth achieving (though IMO I
> think that foo1 should have direct dependencies with foo2_1 and
> foo2_2), but I think that we should decide what is the default
> behavior we want, and implement the additional behavior in a second
> patch, separated from the patch of this thread. Personally I am more a
> fan of propagating to parent extensions the schema of the child and
> not of its grand-child by default, but I am not alone here :)
>

This is something that I as a user of the feature specifically don't
want to happen as I install extensions either to common schema (for some
utility ones) or into separate schemas (for the rest), but I never want
the utility extension to go to the same schema as the other ones. This
is especially true when installing non-relocatable extension which
depends on relocatable one. Obviously, it does not mean that nobody else
wants this though :)

--
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services