"Regina Obe" writes:
>> making the no_relocate values visible somehow, I'm not convinced that
>> pg_available_extension_versions should be the place to do it. ISTM what's
>> relevant is the no_relocate values of *installed* extensions, not those of
>> potentially-installable extensions. If we
> Pushed with some mostly-cosmetic adjustments (in particular I tried to
make
> the docs and tests neater).
>
> I did not commit the changes in get_available_versions_for_extension
> to add no_relocate as an output column. Those were dead code because you
> hadn't done anything to connect them
Sandro Santilli writes:
> On Mon, Mar 13, 2023 at 05:57:57PM -0400, Regina Obe wrote:
>> Attached is a slightly revised patch to fix the extra whitespace in the
>> extend.gml document that Sandro noted to me.
> Thanks Regina.
> I've tested attached patch (md5 0b652a8271fc7e71ed5f712ac162a0ef)
>
On Mon, Mar 13, 2023 at 05:57:57PM -0400, Regina Obe wrote:
>
> Attached is a slightly revised patch to fix the extra whitespace in the
> extend.gml document that Sandro noted to me.
Thanks Regina.
I've tested attached patch (md5 0b652a8271fc7e71ed5f712ac162a0ef)
against current master (hash
> On Sat, Mar 11, 2023 at 03:18:18AM -0500, Regina Obe wrote:
> > Attached is a revised patch with these changes in place.
>
> I've given a try to this patch. It builds and regresses fine.
>
> My own tests also worked fine. As long as ext1 was found in the ext2's
> no_relocate list it could not
> I've given a try to this patch. It builds and regresses fine.
>
> My own tests also worked fine. As long as ext1 was found in the ext2's
> no_relocate list it could not be relocated, and proper error message is
given
> to user trying it.
>
> Nitpicking, there are a few things that are weird to
On Sat, Mar 11, 2023 at 03:18:18AM -0500, Regina Obe wrote:
> Attached is a revised patch with these changes in place.
I've given a try to this patch. It builds and regresses fine.
My own tests also worked fine. As long as ext1 was found
in the ext2's no_relocate list it could not be relocated,
> Subject: Re: Ability to reference other extensions by schema in extension
> scripts
>
> "Regina Obe" writes:
> >> requires = 'extfoo, extbar'
> >> no_relocate = 'extfoo'
>
> > So when no_relocate is specified, where would that live?
>
> In the control file.
>
> > Would I mark the extfoo as
> "Regina Obe" writes:
> >> requires = 'extfoo, extbar'
> >> no_relocate = 'extfoo'
>
> > So when no_relocate is specified, where would that live?
>
> In the control file.
>
> > Would I mark the extfoo as not relocatable on CREATE / ALTER of said
> > extension?
> > Or add an extra field to
"Regina Obe" writes:
>> requires = 'extfoo, extbar'
>> no_relocate = 'extfoo'
> So when no_relocate is specified, where would that live?
In the control file.
> Would I mark the extfoo as not relocatable on CREATE / ALTER of said
> extension?
> Or add an extra field to pg_extension
We don't
> No, pg_depend is not the thing to use for this. I was thinking of a new
field in
> the extension's control file, right beside where it says it's dependent on
such-
> and-such extensions in the first place. Say like
>
> requires = 'extfoo, extbar'
> no_relocate = 'extfoo'
>
So
"Regina Obe" writes:
>> If you want to work harder, perhaps a reasonable way to deal with the issue
>> would be to allow dependent extensions to declare that they don't want your
>> extension relocated. But I do not think it's okay to make that the default
>> behavior, much less the only
> "Regina Obe" writes:
> > [ 0005-Allow-use-of-extschema-reqextname-to-reference.patch ]
>
> I took a look at this. I'm on board with the feature design, but not so
much
> with this undocumented restriction you added to ALTER EXTENSION SET
> SCHEMA:
>
> + /* If an extension
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Friday, March 10, 2023 3:07 PM
> To: Regina Obe
> Cc: 'Gregory Stark (as CFM)' ; 'Sandro Santilli'
> ; pgsql-hackers@lists.postgresql.org; 'Regina Obe'
>
> Subject: Re: Ability to reference other extensions by
"Regina Obe" writes:
> [ 0005-Allow-use-of-extschema-reqextname-to-reference.patch ]
I took a look at this. I'm on board with the feature design,
but not so much with this undocumented restriction you added
to ALTER EXTENSION SET SCHEMA:
+ /* If an extension requires this
> It looks like this patch needs a quick rebase, there's a conflict in the
> meson.build.
>
> I'll leave the state since presumably this would be easy to resolve but it
> would
> be more likely to get attention if it's actually building cleanly.
>
> http://cfbot.cputube.org/patch_42_4023.log
>
> It looks like this patch needs a quick rebase, there's a conflict in the
> meson.build.
>
> I'll leave the state since presumably this would be easy to resolve but it
> would
> be more likely to get attention if it's actually building cleanly.
>
> http://cfbot.cputube.org/patch_42_4023.log
>
It looks like this patch needs a quick rebase, there's a conflict in
the meson.build.
I'll leave the state since presumably this would be easy to resolve
but it would be more likely to get attention if it's actually building
cleanly.
http://cfbot.cputube.org/patch_42_4023.log
On Tue, 28 Feb
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
I've applied the patch attached to message
> On Sun, Feb 26, 2023 at 01:39:24AM -0500, Regina Obe wrote:
>
> > > 1) Just don't allow any extensions referenced by other
> > >extensions to be relocatable.
> >
> > Attached is my revision 3 patch, which follows the proposed #1.
> > Don't allow schema relocation of an extension if another
On Sun, Feb 26, 2023 at 01:39:24AM -0500, Regina Obe wrote:
> > 1) Just don't allow any extensions referenced by other
> >extensions to be relocatable.
>
> Attached is my revision 3 patch, which follows the proposed #1.
> Don't allow schema relocation of an extension if another extension
>
On Sat, Feb 25, 2023 at 03:40:24PM -0500, Regina Obe wrote:
> > On Mon, Feb 06, 2023 at 05:19:39AM -0500, Regina Obe wrote:
> >
> > I was thinking: how about using the "refobjsubid" to encode the "level" of
> > dependency on an extension ? Right now "refobjsubid" is always 0 when the
> >
> So in conclusion we have 3 possible paths to go with this
>
> 1) Just don't allow any extensions referenced by other extensions to be
> relocatable.
> It will show a message something like
> "SET SCHEMA not allowed because other extensions depend on it"
> Given that if you don't specify
> On Mon, Feb 06, 2023 at 05:19:39AM -0500, Regina Obe wrote:
> >
> > Attached is a revised version of the original patch. It is revised to
> > prevent
> >
> > ALTER EXTENSION .. SET SCHEMA if there is a dependent extension that
> > references the extension in their scripts using
> >
On Mon, Feb 06, 2023 at 05:19:39AM -0500, Regina Obe wrote:
>
> Attached is a revised version of the original patch. It is revised to
> prevent
>
> ALTER EXTENSION .. SET SCHEMA if there is a dependent extension that
> references the extension in their scripts using @extschema:extensionname@
> > > Here is first version of my patch using the
> > > @extschema:extensionname@ syntax you proposed.
> > >
> > > This patch includes:
> > > 1) Changes to replace references of @extschema:extensionname@ with
> > > the schema of the required extension
> > > 2) Documentation for the feature
> > >
> On Mon, Jan 16, 2023 at 11:57:30PM -0500, Regina Obe wrote:
>
> > What would be more bullet-proof is having an extra column in
> > pg_extension or adding an extra array element to
> > pg_extension.extcondition[] that allows you to say "Hey, don't allow
> > this to be relocatable cause other
On Mon, Jan 16, 2023 at 11:57:30PM -0500, Regina Obe wrote:
> What would be more bullet-proof is having an extra column in pg_extension or
> adding an extra array element to pg_extension.extcondition[] that allows you
> to say "Hey, don't allow this to be relocatable cause other extensions
>
>
> On Thu, Dec 15, 2022 at 08:04:22AM -0500, Regina Obe wrote:
> > > On Tue, Nov 22, 2022 at 11:24:19PM -0500, Regina Obe wrote:
> > >
> > > > If an extension is required by another extension and that required
> > > > extension schema is referenced in the extension scripts using the
> > > >
On Thu, Dec 15, 2022 at 08:04:22AM -0500, Regina Obe wrote:
> > On Tue, Nov 22, 2022 at 11:24:19PM -0500, Regina Obe wrote:
> >
> > > If an extension is required by another extension and that required
> > > extension schema is referenced in the extension scripts using the
> > >
> On Tue, Nov 22, 2022 at 11:24:19PM -0500, Regina Obe wrote:
>
> > Here is first version of my patch using the @extschema:extensionname@
> > syntax you proposed.
> >
> > This patch includes:
> > 1) Changes to replace references of @extschema:extensionname@ with the
> > schema of the required
On Tue, Nov 22, 2022 at 11:24:19PM -0500, Regina Obe wrote:
> Here is first version of my patch using the @extschema:extensionname@ syntax
> you proposed.
>
> This patch includes:
> 1) Changes to replace references of @extschema:extensionname@ with the
> schema of the required extension
> 2)
>
> "Regina Obe" writes:
> >> I have a distinct sense of deja vu here. I think this idea, or
> >> something isomorphic to it, was previously discussed with some other
> syntax details.
>
> > I found the old discussion I recalled having and Stephen had suggested
> > using @extschema{'postgis'}@
> "Regina Obe" writes:
> >> I have a distinct sense of deja vu here. I think this idea, or
> >> something isomorphic to it, was previously discussed with some other
> syntax details.
>
> > I found the old discussion I recalled having and Stephen had suggested
> > using @extschema{'postgis'}@ On
"Regina Obe" writes:
>> I have a distinct sense of deja vu here. I think this idea, or something
>> isomorphic to it, was previously discussed with some other syntax details.
> I found the old discussion I recalled having and Stephen had suggested using
> @extschema{'postgis'}@
> On this thread
> "Regina Obe" writes:
> > My proposal is this. If you think it's a good enough idea I can work
> > up a patch for this.
> > Extensions currently are allowed to specify a requires in the control
file.
> > I propose to use this information, to allow replacement of phrases
> >
"Regina Obe" writes:
> My proposal is this. If you think it's a good enough idea I can work up a
> patch for this.
> Extensions currently are allowed to specify a requires in the control file.
> I propose to use this information, to allow replacement of phrases
> @extschema_nameofextension@ as
37 matches
Mail list logo
