creating extension including dependencies

+1

Is it working in runtime too?
Dne 15.6.2015 0:51 napsal uživatel "Petr Jelinek" <petr@2ndquadrant.com>:

On 06/15/2015 12:50 AM, Petr Jelinek wrote:

Hi,

I am getting tired installing manually required extensions manually. I
was wondering if we might want to add option to CREATE SEQUENCE that
would allow automatic creation of the extensions required by the
extension that is being installed by the user.

I would like this, too.

I call it prototype mainly because the syntax (CREATE EXTENSION ...
RECURSIVE) could be improved, I originally wanted to do something like
INCLUDING DEPENDENCIES but that need news (unreserved) keyword and I
don't think it's worth it, plus it's wordy.

If we're bikeshedding already, I prefer CREATE EXTENSION ... CASCADE;
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Jun 15, 2015 at 7:50 AM, Petr Jelinek <petr@2ndquadrant.com> wrote:

Hi,

I am getting tired installing manually required extensions manually. I was
wondering if we might want to add option to CREATE SEQUENCE that would allow
automatic creation of the extensions required by the extension that is being
installed by the user.

I'm wondering how much helpful this feature is. Because, even if we can save
some steps for CREATE EXTENSION by using the feature, we still need to
manually find out, download and install all the extensions that the target
extension depends on. So isn't it better to implement the tool like yum, i.e.,
which performs all those steps almost automatically, rather than the proposed
feature? Maybe it's outside PostgreSQL core.

Regards,

--
Fujii Masao

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2015-07-07 22:36:29 +0900, Fujii Masao wrote:

On Mon, Jun 15, 2015 at 7:50 AM, Petr Jelinek <petr@2ndquadrant.com> wrote:

Hi,

I am getting tired installing manually required extensions manually. I was
wondering if we might want to add option to CREATE SEQUENCE that would allow
automatic creation of the extensions required by the extension that is being
installed by the user.

I'm wondering how much helpful this feature is. Because, even if we can save
some steps for CREATE EXTENSION by using the feature, we still need to
manually find out, download and install all the extensions that the target
extension depends on. So isn't it better to implement the tool like yum, i.e.,
which performs all those steps almost automatically, rather than the proposed
feature? Maybe it's outside PostgreSQL core.

That doesn't seem to make much sense to me. Something like yum can't
install everything in all relevant databases. Sure, yum will be used to
install dependencies between extensions on the filesystem level.

At the minimum I'd like to see that CREATE EXTENSION foo; would install
install extension 'bar' if foo dependended on 'bar' if CASCADE is
specified. Right now we always error out saying that the dependency on
'bar' is not fullfilled - not particularly helpful.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Jul 7, 2015, at 6:41 AM, Andres Freund <andres@anarazel.de> wrote:

At the minimum I'd like to see that CREATE EXTENSION foo; would install
install extension 'bar' if foo dependended on 'bar' if CASCADE is
specified. Right now we always error out saying that the dependency on
'bar' is not fullfilled - not particularly helpful.

+1

If `yum install foo` also installs bar, and `pgxn install foo` downloads, builds, and installs bar, it makes sense to me that `CREATE EXTENSION foo` would install bar if it was available, and complain if it wasn’t.

Best,

David

On 2015-07-07 15:41, Andres Freund wrote:

On 2015-07-07 22:36:29 +0900, Fujii Masao wrote:

On Mon, Jun 15, 2015 at 7:50 AM, Petr Jelinek <petr@2ndquadrant.com> wrote:

Hi,

I am getting tired installing manually required extensions manually. I was
wondering if we might want to add option to CREATE SEQUENCE that would allow
automatic creation of the extensions required by the extension that is being
installed by the user.

I'm wondering how much helpful this feature is. Because, even if we can save
some steps for CREATE EXTENSION by using the feature, we still need to
manually find out, download and install all the extensions that the target
extension depends on. So isn't it better to implement the tool like yum, i.e.,
which performs all those steps almost automatically, rather than the proposed
feature? Maybe it's outside PostgreSQL core.

That doesn't seem to make much sense to me. Something like yum can't
install everything in all relevant databases. Sure, yum will be used to
install dependencies between extensions on the filesystem level.

At the minimum I'd like to see that CREATE EXTENSION foo; would install
install extension 'bar' if foo dependended on 'bar' if CASCADE is
specified. Right now we always error out saying that the dependency on
'bar' is not fullfilled - not particularly helpful.

That's what the proposed patch does (with slightly different syntax but
syntax is something that can be changed easily).

--
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

On 07/09/2015 07:05 PM, Petr Jelinek wrote:

On 2015-07-07 15:41, Andres Freund wrote:

On 2015-07-07 22:36:29 +0900, Fujii Masao wrote:

On Mon, Jun 15, 2015 at 7:50 AM, Petr Jelinek <petr@2ndquadrant.com> wrote:

Hi,

I am getting tired installing manually required extensions manually. I was
wondering if we might want to add option to CREATE SEQUENCE that would allow
automatic creation of the extensions required by the extension that is being
installed by the user.

I'm wondering how much helpful this feature is. Because, even if we can save
some steps for CREATE EXTENSION by using the feature, we still need to
manually find out, download and install all the extensions that the target
extension depends on. So isn't it better to implement the tool like yum, i.e.,
which performs all those steps almost automatically, rather than the proposed
feature? Maybe it's outside PostgreSQL core.

That doesn't seem to make much sense to me. Something like yum can't
install everything in all relevant databases. Sure, yum will be used to
install dependencies between extensions on the filesystem level.

At the minimum I'd like to see that CREATE EXTENSION foo; would install
install extension 'bar' if foo dependended on 'bar' if CASCADE is
specified. Right now we always error out saying that the dependency on
'bar' is not fullfilled - not particularly helpful.

That's what the proposed patch does (with slightly different syntax but
syntax is something that can be changed easily).

This seems quite reasonable, but I have to ask: How many extensions are
there out there that depend on another extension? Off the top of my
head, I can't think of any..

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Jul 10, 2015 at 10:09 PM, Heikki Linnakangas <hlinnaka@iki.fi>
wrote:

On 07/09/2015 07:05 PM, Petr Jelinek wrote:

On 2015-07-07 15:41, Andres Freund wrote:

On 2015-07-07 22:36:29 +0900, Fujii Masao wrote:

On Mon, Jun 15, 2015 at 7:50 AM, Petr Jelinek <petr@2ndquadrant.com>
wrote:

Hi,

I am getting tired installing manually required extensions manually. I
was
wondering if we might want to add option to CREATE SEQUENCE that would
allow
automatic creation of the extensions required by the extension that is
being
installed by the user.

I'm wondering how much helpful this feature is. Because, even if we can
save
some steps for CREATE EXTENSION by using the feature, we still need to
manually find out, download and install all the extensions that the
target
extension depends on. So isn't it better to implement the tool like
yum, i.e.,
which performs all those steps almost automatically, rather than the
proposed
feature? Maybe it's outside PostgreSQL core.

That doesn't seem to make much sense to me. Something like yum can't
install everything in all relevant databases. Sure, yum will be used to
install dependencies between extensions on the filesystem level.

At the minimum I'd like to see that CREATE EXTENSION foo; would install
install extension 'bar' if foo dependended on 'bar' if CASCADE is
specified. Right now we always error out saying that the dependency on
'bar' is not fullfilled - not particularly helpful.

That's what the proposed patch does (with slightly different syntax but
syntax is something that can be changed easily).

This seems quite reasonable, but I have to ask: How many extensions are
there out there that depend on another extension? Off the top of my head, I
can't think of any..

With transforms there are such dependencies, and there are 3 in contrib/:
hstore_plperl, hstore_plpython and ltree_plpython.
--
Michael

On 2015-07-10 16:09:48 +0300, Heikki Linnakangas wrote:

This seems quite reasonable, but I have to ask: How many extensions are
there out there that depend on another extension? Off the top of my head, I
can't think of any..

BDR/UDR is one (or two depending on your POV).

I think a part of why there are not more is that the dependencies right
now are painful.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

10 июля 2015 г., в 16:09, Heikki Linnakangas <hlinnaka@iki.fi> написал(а):

On 07/09/2015 07:05 PM, Petr Jelinek wrote:

On 2015-07-07 15:41, Andres Freund wrote:

On 2015-07-07 22:36:29 +0900, Fujii Masao wrote:

On Mon, Jun 15, 2015 at 7:50 AM, Petr Jelinek <petr@2ndquadrant.com> wrote:

Hi,

I am getting tired installing manually required extensions manually. I was
wondering if we might want to add option to CREATE SEQUENCE that would allow
automatic creation of the extensions required by the extension that is being
installed by the user.

I'm wondering how much helpful this feature is. Because, even if we can save
some steps for CREATE EXTENSION by using the feature, we still need to
manually find out, download and install all the extensions that the target
extension depends on. So isn't it better to implement the tool like yum, i.e.,
which performs all those steps almost automatically, rather than the proposed
feature? Maybe it's outside PostgreSQL core.

That doesn't seem to make much sense to me. Something like yum can't
install everything in all relevant databases. Sure, yum will be used to
install dependencies between extensions on the filesystem level.

At the minimum I'd like to see that CREATE EXTENSION foo; would install
install extension 'bar' if foo dependended on 'bar' if CASCADE is
specified. Right now we always error out saying that the dependency on
'bar' is not fullfilled - not particularly helpful.

That's what the proposed patch does (with slightly different syntax but
syntax is something that can be changed easily).

This seems quite reasonable, but I have to ask: How many extensions are there out there that depend on another extension? Off the top of my head, I can't think of any..

pg_stat_kcache depends on pg_stat_statements, for example.

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org <mailto:pgsql-hackers@postgresql.org>)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers <http://www.postgresql.org/mailpref/pgsql-hackers&gt;

--
May the force be with you…
https://simply.name

Michael Paquier <michael.paquier@gmail.com> writes:

On Fri, Jul 10, 2015 at 10:09 PM, Heikki Linnakangas <hlinnaka@iki.fi>

This seems quite reasonable, but I have to ask: How many extensions are
there out there that depend on another extension? Off the top of my head, I
can't think of any..

With transforms there are such dependencies, and there are 3 in contrib/:
hstore_plperl, hstore_plpython and ltree_plpython.

It's reasonable to expect that such cases will become more common as the
extension community matures. It wasn't something we especially had to
worry about in the initial implementation of extensions, but it seems
totally worthwhile to me to add it now.

FWIW, I agree with using "CASCADE" to signal a request to create required
extension(s) automatically.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2015-06-15 00:50:08 +0200, Petr Jelinek wrote:

+				/* Create and execute new CREATE EXTENSION statement. */
+				ces = makeNode(CreateExtensionStmt);
+				ces->extname = curreq;
+				ces->if_not_exists = false;
+				parents = lappend(list_copy(recursive_parents), stmt->extname);
+				ces->options = list_make1(makeDefElem("recursive",
+													  (Node *) parents));
+				CreateExtension(ces);

I think we should copy the SCHEMA option here and document that we use
the same schema. But it needs to be done in a way that doesn't error out
if the extension is not relocatable...

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andres Freund <andres@anarazel.de> writes:

I think we should copy the SCHEMA option here and document that we use
the same schema. But it needs to be done in a way that doesn't error out
if the extension is not relocatable...

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.)

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On July 10, 2015 4:16:59 PM GMT+02:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andres Freund <andres@anarazel.de> writes:

I think we should copy the SCHEMA option here and document that we

use

the same schema. But it needs to be done in a way that doesn't error

out

if the extension is not relocatable...

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.

Andres

--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Jul 07, 2015 at 10:14:49AM -0700, David E. Wheeler wrote:

On Jul 7, 2015, at 6:41 AM, Andres Freund <andres@anarazel.de> wrote:

At the minimum I'd like to see that CREATE EXTENSION foo; would
install install extension 'bar' if foo dependended on 'bar' if
CASCADE is specified. Right now we always error out saying that
the dependency on 'bar' is not fullfilled - not particularly
helpful.

+1

If `yum install foo` also installs bar, and `pgxn install foo`
downloads, builds, and installs bar, it makes sense to me that
`CREATE EXTENSION foo` would install bar if it was available, and
complain if it wasn’t.

This is this baseline sane behavior. Getting the full dependency
tree, although it would be very handy, would require more
infrastructure than we have now.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 just had a look at this patch, and here are some comments:
+ [ RECURSIVE ]
After reading the thread, CASCADE sounds like a good thing as well to me.

+                               /* Create and execute new CREATE
EXTENSION statement. */
+                               ces = makeNode(CreateExtensionStmt);
+                               ces->extname = curreq;
+                               ces->if_not_exists = false;
+                               parents =
lappend(list_copy(recursive_parents), stmt->extname);
+                               ces->options =
list_make1(makeDefElem("recursive",
+
                                   (Node *) parents));
+                               CreateExtension(ces);
+                               list_free(parents);
ces should be free'd after calling CreateExtension perhaps?

The test_ext*--*.sql files should not be completely empty. They should
include a header like this one (hoge is the Japanese foo...):
/* src/test/modules/test_extension/hoge--1.0.sql */
-- complain if script is sourced in psql, rather than via CREATE EXTENSION
\echo Use "CREATE EXTENSION hoge" to load this file. \quit

That is good practice compared to the other modules, and this way
there is no need to have Makefile for example touch'ing those files
before installing them (I have created them manually to test this
patch).

The list of contrib modules excluded from build in the case of MSVC
needs to include test_extensions ($contrib_excludes in
src/tools/msvc/Mkvcbuild.pm) or build on Windows using MS of VC will
fail. commit_ts does that for example.

Regression tests of contrib/ modules doing transforms should be
updated to use this new stuff IMO. That's not part of the core patch
obviously, but it looks worth including them as well.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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).

I just had a look at this patch, and here are some comments:
+ [ RECURSIVE ]
After reading the thread, CASCADE sounds like a good thing as well to me.

Yep, got that much :)

+                               /* Create and execute new CREATE
EXTENSION statement. */
+                               ces = makeNode(CreateExtensionStmt);
+                               ces->extname = curreq;
+                               ces->if_not_exists = false;
+                               parents =
lappend(list_copy(recursive_parents), stmt->extname);
+                               ces->options =
list_make1(makeDefElem("recursive",
+
(Node *) parents));
+                               CreateExtension(ces);
+                               list_free(parents);
ces should be free'd after calling CreateExtension perhaps?

Yeah and the exercise with list_copy and list_free on parents is
probably not needed.

The test_ext*--*.sql files should not be completely empty. They should
include a header like this one (hoge is the Japanese foo...):
/* src/test/modules/test_extension/hoge--1.0.sql */
-- complain if script is sourced in psql, rather than via CREATE EXTENSION
\echo Use "CREATE EXTENSION hoge" to load this file. \quit

Done.

The list of contrib modules excluded from build in the case of MSVC
needs to include test_extensions ($contrib_excludes in
src/tools/msvc/Mkvcbuild.pm) or build on Windows using MS of VC will
fail. commit_ts does that for example.

Done, hopefully correctly, I don't have access to MSVC.

Regression tests of contrib/ modules doing transforms should be
updated to use this new stuff IMO. That's not part of the core patch
obviously, but it looks worth including them as well.

Done.

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

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.

And actually by looking at the code I can guess that when DEFAULT
SCHEMA is used and that a non-relocatable extension with a schema
defined is created in cascade this will error-out as well. That's not
really user-friendly..

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 :)

The list of contrib modules excluded from build in the case of MSVC
needs to include test_extensions ($contrib_excludes in
src/tools/msvc/Mkvcbuild.pm) or build on Windows using MS of VC will
fail. commit_ts does that for example.

Done, hopefully correctly, I don't have access to MSVC.

That's done correctly.

+                               /*
+                                * Propagate the CASCADE option and
add current extenssion
+                                * to the list for checking the cyclic
dependencies.
+                                */
s/extenssion/extension/

+ /* Check for cyclic dependency between
extension. */
s/extension/extensions/

psql tab completion should be completed with cascade. See the part
with WITH SCHEMA in tab-complete.c.

Regards,
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers