On 2015-07-21 15:48, Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
On Mon, Jul 20, 2015 at 10:29 PM, Michael Paquier
<michael.paqu...@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
