Re: creating extension including dependencies

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: creating extension including dependencies
Date: 2015-07-21 14:14:46
Message-ID: 55AE53D6.9060205@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-07-21 15:48, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Jul 20, 2015 at 10:29 PM, Michael Paquier
>> <michael(dot)paquier(at)gmail(dot)com> wrote:>
>>> In short I would give up on the DEFAULT SCHEMA business, and
>>> add a new flag in the control file to decide if a given extension
>>> passes down the schema name of its child when created in cascade,
>>> default being true for the potential issues with search_path not
>>> pointing to public.
>
>> Well, so far, it seems like this decision is something where different
>> DBAs might have different policies. If you put the flag in the
>> control file, you're saying it is the extension developer's decision,
>> which may not be best.
>
> I have doubts about that too. But really, why have a flag at all
> anywhere? If we are doing a CASCADE, and the referenced extension needs a
> schema, the alternatives are either (1) let it have one, or (2) fail.
> I am not seeing that (2) is a superior alternative in any circumstances.
>
> We will need to document that the behavior of CASCADE is "install all
> needed extensions into the schema you specify", but what's wrong with
> that? If the user wants to put them in different schemas, he cannot
> use CASCADE in any case.
>

Yes this is the behavior I want as well. My main question is if we are
ok with SCHEMA having different behavior with CASCADE vs without
CASCADE. I went originally with "no" and added the DEFAULT flag to
SCHEMA. If the answer is "yes" then we don't need the flag (in that case
CASCADE acts as the flag).

Or course "yes" would then mean "CREATE EXTENSION foo SCHEMA bar" will
fail if "foo" is not relocatable but "CREATE EXTENSION foo SCHEMA bar
CASCADE" will succeed and install "foo" into schema "foo" instead of
"bar" and only relocatable dependencies will go to "bar". OTOH
non-relocatable dependencies will go to their own schema no matter what
user specifies in the command so I guess it's ok to just document that
this is the behavior of CASCADE. As you say if somebody wants control
over each individual extension they can't use CASCADE anyway.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-07-21 14:20:12 Re: creating extension including dependencies
Previous Message Teodor Sigaev 2015-07-21 14:14:39 Re: Selectivity estimation for intarray with @@