On Thu, Feb 01, 2024 at 04:31:26PM +0530, vignesh C wrote:
>
> With no update to the thread and the tests still failing I'm marking
> this as returned with feedback. Please feel free to resubmit to the
> next CF when there is a new version of the patch.
Ok, no problem. Thank you.
--strk;
sign
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@
>
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
> > reference
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
> re
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
https://www.postg
ingle ANY-- upgrade path, but we
are still REQUIRED to install a file for any we
want to allow upgrade from, which is what this patch is aimed
at fixing.
--strk;
>From ffefd039f24e3def8d2216b3ac7875d0b6feb8fb Mon Sep 17 00:00:00 2001
From: Sandro Santilli
Date: Wed, 14 Sep 2022 11:10:10 +020
On Tue, Mar 07, 2023 at 12:39:34PM -0500, Robert Haas wrote:
> The thing that confuses me here is why the PostGIS folks are ending up
> with so many files.
We want to allow PostGIS users to upgrade from ANY previous version,
because different distribution or user habit may result in people
upgrad
On Tue, Mar 07, 2023 at 02:13:07PM -0500, Tom Lane wrote:
> What I am maintaining is that no extension author is actually going
> to write such a script, indeed they probably won't trouble to write
> any downgrade-like actions at all. Which makes the proposed design
> mostly a foot-gun.
What I'm
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,
a
On Wed, Mar 08, 2023 at 08:27:29AM -0500, Robert Haas wrote:
> I wonder if a solution to this problem might be to provide some kind
> of a version map file. Let's suppose that the map file is a bunch of
> lines of the form X Y Z, where X, Y, and Z are version numbers. The
> semantics could be: we
On Wed, Mar 08, 2023 at 03:18:06PM -0500, Regina Obe wrote:
>
> Then question arises if you have such a map file and you have files as well
> (the old way).
One idea I had in the past about the .control file was to
advertise an executable that would take current version and next
version and retu
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 4ef1
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) Docu
On Mon, Jan 09, 2023 at 05:51:49PM -0500, Tom Lane wrote:
> Have you considered the idea of instead inventing a "\include" facility
[...]
> cases, you still need one script file for each supported upgrade step
That's exactly the problem we're trying to solve here.
The include support is nice on
On Tue, Jan 10, 2023 at 06:50:31PM -0500, Tom Lane wrote:
> With the proposed % feature, if foo--%--3.0.sql exists then the
> system will invoke it and expect the end result to be a valid
> 3.0 installation, whether or not the script actually has any
> ability to do a downgrade.
It is sane, for
On Tue, Jan 10, 2023 at 11:09:23PM -0500, Regina Obe wrote:
> The only way we can fix that in the current setup, is to move to a minor
> version mode which means we can
> never do micro updates.
Or just not with standard PostgreSQL syntax, because we can of course
do upgrades using the `SELECT p
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
> > > @extschema:extensio
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
> depen
>
> 3.2.%--3.4.0 = 3.2--3.4.0
I could implement this too if there's an agreement about it.
For now I'm attaching an updated patch with conflicts resolved.
--strk;
>From a10a1a7200f76bbc6e2def8d4684b647a99316cd Mon Sep 17 00:00:00 2001
From: Sandro Santilli
Date: Wed, 14 Sep 2
On Mon, Apr 03, 2023 at 09:26:25AM +0700, Yurii Rashkovskii wrote:
> I want to chime in on the issue of lower-number releases that are released
> after higher-number releases. The way I see this particular problem is that
> we always put upgrade SQL files in release "packages," and they obviously
>
On Mon, Apr 10, 2023 at 11:09:40PM -0400, Regina Obe wrote:
> > On Mon, Apr 03, 2023 at 09:26:25AM +0700, Yurii Rashkovskii wrote:
> > > I want to chime in on the issue of lower-number releases that are
> > > released after higher-number releases. The way I see this particular
> > > problem is that
On Tue, Apr 11, 2023 at 04:36:04PM -0400, Regina Obe wrote:
>
> > Hey, best would be having support for wildcard wouldn't it ?
>
> I'm a woman of compromise. Sure 1 file would be ideal, but
> I'd rather live with a big file listing all version upgrades
> than 1000 files with the same information
On Fri, Apr 21, 2023 at 11:48:51AM -0400, Tom Lane wrote:
> "Regina Obe" writes:
>
> > https://trac.osgeo.org/postgis/ticket/5375
>
> If they actually are using locale C, I would say this is a bug.
> That should designate memcmp sorting and nothing else.
Sounds like a bug to me. This is happeni
On Fri, Apr 21, 2023 at 07:14:13PM +0200, Peter Eisentraut wrote:
> On 21.04.23 19:09, Sandro Santilli wrote:
> > On Fri, Apr 21, 2023 at 11:48:51AM -0400, Tom Lane wrote:
> > > "Regina Obe" writes:
> > >
> > > > https://trac.osgeo.org/postgis/ti
On Fri, Apr 21, 2023 at 10:27:49AM -0700, Jeff Davis wrote:
> On Fri, 2023-04-21 at 19:09 +0200, Sandro Santilli wrote:
> > =# select version();
> > PostgreSQL 16devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
> > 11.3.0-1ubuntu1~22.04) 11.3.0, 64-bit
> >
On Mon, Apr 24, 2023 at 01:06:24PM -0400, Mat Arye wrote:
> Hi All,
>
> I've done upgrade maintenance for multiple extensions now (TimescaleDB
> core, Promscale) and I think the original suggestion (wildcard filenames
> with control-file switch to enable) here is a good one.
Thanks for your comme
tml
>From e9d060b19c655924c4edb6679169261d605f735d Mon Sep 17 00:00:00 2001
From: Sandro Santilli
Date: Fri, 11 Feb 2022 18:49:45 +0100
Subject: [PATCH] Support % wildcard in extension upgrade scripts
---
src/backend/commands/extension.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sr
hen doing so).
--strk;
>From 8725c616c31a9bc25478c7128ea81ce753e51089 Mon Sep 17 00:00:00 2001
From: Sandro Santilli
Date: Wed, 14 Sep 2022 11:10:10 +0200
Subject: [PATCH] Allow wildcard (%) in extension upgrade paths
A wildcard character "%" will be accepted in the
"source" side of the u
And now a version of the patch including documentation and regression tests.
Anything you see I should improve ?
--strk;
On Fri, Nov 04, 2022 at 06:31:58PM +0100, Sandro Santilli wrote:
> On Mon, Oct 31, 2022 at 01:55:05AM -0400, Regina Obe wrote:
> >
> > Sandro, can you su
On Sun, Nov 13, 2022 at 11:46:50PM -0500, Regina Obe wrote:
> > Re: Sandro Santilli
> > > I'm attaching an updated version of the patch. This time the patch is
> > > tested. Nothing changes unless the .control file for the subject
> > > extension doesn't
strk;
>From 344f2b96c172ed8c75990ecb86e78494c82df54d Mon Sep 17 00:00:00 2001
From: Sandro Santilli
Date: Wed, 14 Sep 2022 11:10:10 +0200
Subject: [PATCH] Allow wildcard (%) in extension upgrade paths
A wildcard character "%" will be accepted in the
"source" side of the upgrade script a
On Sat, May 28, 2022 at 04:50:20PM +0200, Laurenz Albe wrote:
> On Fri, 2022-05-27 at 17:37 -0400, Regina Obe wrote:
> >
> > https://lists.osgeo.org/pipermail/postgis-devel/2022-February/029500.html
> >
> > Does anyone think this is such a horrible idea that we should abandon all
> > hope?
>
> I
On Sat, May 28, 2022 at 05:26:05PM +0200, Daniel Gustafsson wrote:
> > On 28 May 2022, at 16:50, Laurenz Albe wrote:
>
> > I don't think this idea is fundamentally wrong, but I have two worries:
> >
> > 1. It would be a good idea good to make sure that there is not both
> > "extension--%--2.0.sq
On Sat, May 28, 2022 at 11:37:30AM -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > 2. What if you have a "postgis--%--3.3.sql", and somebody tries to upgrade
> >their PostGIS 1.1 installation with it? Would that work?
> >Having a lower bound for a matching version might be a good idea,
On Tue, Aug 01, 2023 at 08:24:15PM +0200, Daniel Gustafsson wrote:
> > On 28 Jun 2023, at 10:29, Daniel Gustafsson wrote:
> >
> >> On 31 May 2023, at 21:07, Sandro Santilli wrote:
> >> On Thu, Apr 27, 2023 at 12:49:57PM +0200, Sandro Santilli wrote:
> >
This is the intention. The patch lacks automated tests and can
probably be improved.
For more context, a previous (non-working) version of this patch was
submitted to commitfest: https://commitfest.postgresql.org/38/3654/
--strk;
On Sat, Jun 04, 2022 at 11:20:55AM +0200, Sandro Santilli wrote:
&g
And now with the actual patch attached ... (sorry)
--strk;
On Thu, Sep 15, 2022 at 12:01:04AM +0200, Sandro Santilli wrote:
> I'm attaching an updated version of the patch. This time the patch
> is tested. Nothing changes unless the .control file for the subject
> extension
On Thu, May 18, 2023 at 11:14:52PM +0200, Przemysław Sztoch wrote:
> For me, it would be a big help if you could specify a simple from/to range
> as the source version:
> myext--1.0.0-1.9.9--2.0.0.sql
> myext--2.0.0-2.9.9--3.0.0.sql
> myext--3.0.0-3.2.3--3.2.4.sql
>
> The idea of % wildcard in my
On Thu, Apr 27, 2023 at 12:49:57PM +0200, Sandro Santilli wrote:
> On Mon, Apr 24, 2023 at 01:06:24PM -0400, Mat Arye wrote:
> > Hi All,
> >
> > I've done upgrade maintenance for multiple extensions now (TimescaleDB
> > core, Promscale) and I think the origina
On Thu, Feb 13, 2020 at 07:09:18PM -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> It seems to me that FROM UNPACKAGED shouldn't support trusted.
>
> > Hmm, seems like a reasonable idea, but I'm not quite sure how to mechanize
> > it given that "unpackaged" isn't magic in any way
On Wed, Feb 26, 2020 at 12:17:37AM -0800, Andres Freund wrote:
> Hi,
>
> On 2020-02-26 09:11:21 +0100, Sandro Santilli wrote:
> > PostGIS uses unpackaged-to-XXX pretty heavily, and has it under
> > automated testing (which broke since "FROM unpackaged" support was
On Wed, Feb 26, 2020 at 08:55:03AM -0500, Stephen Frost wrote:
> Greetings,
>
> * Darafei "Komяpa" Praliaskouski (m...@komzpa.net) wrote:
> > PostGIS 2.5 had raster and vector blended together in single extension.
> > In PostGIS 3, they were split out into postgis and postgis_raster
> > extension
On Wed, Feb 26, 2020 at 03:35:46PM +0100, Daniel Gustafsson wrote:
> > On 26 Feb 2020, at 15:13, Sandro Santilli wrote:
>
> > On pgsql-hackers we only want to find a future-proof way to "package
> > existing objects into an extension".
>
> What is the longt
On Wed, Feb 26, 2020 at 10:37:41AM -0500, Stephen Frost wrote:
> Greetings,
>
> * Sandro Santilli (s...@kbt.io) wrote:
> > On pgsql-hackers we only want to find a future-proof way to "package
> > existing objects into an extension". If the syntax
> > `CREATE
On Wed, Feb 26, 2020 at 11:18:43AM -0500, Chapman Flack wrote:
> On 2/26/20 10:52 AM, Sandro Santilli wrote:
>
> > This part is not clear to me. You're _assuming_ that the unpackaged--xxx
> > will not make checks, so you _drop_ support for it ? Can't the normal
> &g
On Thu, Feb 27, 2020 at 09:32:24AM +0100, Sandro Santilli wrote:
> On Wed, Feb 26, 2020 at 11:18:43AM -0500, Chapman Flack wrote:
> > On 2/26/20 10:52 AM, Sandro Santilli wrote:
> >
> > > This part is not clear to me. You're _assuming_ that the unpackaged--xxx
>
46 matches
Mail list logo
