Re: creating extension including dependencies - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: creating extension including dependencies
Date
Msg-id 55BA2D94.9040309@2ndquadrant.com
Whole thread Raw
In response to Re: creating extension including dependencies  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: creating extension including dependencies  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On 2015-07-27 15:18, Michael Paquier wrote:
> On Sun, Jul 26, 2015 at 1:01 AM, Petr Jelinek wrote:
>> Yes that's what I meant by the change of checking order in the explanation
>> above. I did that because I thought code would be more complicated
>> otherwise, but apparently I was stupid...
>
> +        In case the extension specifies schema in its control file, the schema
> s/schema/<literal>schema</>/
>
> +++ b/src/test/modules/test_extensions/.gitignore
> @@ -0,0 +1,3 @@
> +# Generated subdirectories
> +/results/
> +/tmp_check/
> test_extensions/.gitignore is missing /log/.
>
> Something also has not been discussed yet: what to do with new_version
> and old_version (the options of CreateExtensionStmt)? As of now if
> those options are defined they are not passed down to the parent
> extensions but shouldn't we raise an error if they are used in
> combination with CASCADE? In any case, I think that the behavior
> chosen should be documented.
>

I don't see why we should raise error, they are used just for the 
top-level extension and I think it makes sense that way. CASCADE 
documentation says SCHEMA option is cascaded to required extensions, do 
we need to say something more than that (ie explicitly saying that the 
old_version and new_version aren't)?

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



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: [COMMITTERS] pgsql: Row-Level Security Policies (RLS)
Next
From: Simon Riggs
Date:
Subject: Re: 64-bit XIDs again