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;
On Sun, 7 Jan 2024 at 12:36, vignesh C wrote:
>
> On Mon, 7 Aug 2023 at 19:25, Sandro Santilli wrote:
> >
> > 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
On Mon, 7 Aug 2023 at 19:25, Sandro Santilli wrote:
>
> 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,
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:
> >
> >>> I'm happy to bring back the
On Tue, Aug 1, 2023 at 3:23 PM Daniel Gustafsson wrote:
> I don't disagree with that, but there is nothing preventing that discussion to
> continue here or on other threads. The fact that consensus is that far away
> and no patch that applies exist seems to me to indicate that a new CF entry is
> > On 1 Aug 2023, at 20:45, Robert Haas wrote:
> >
> > On Tue, Aug 1, 2023 at 2:24 PM Daniel Gustafsson
> wrote:
> >> returned with feedback. Please feel free to resubmit to a future CF
> >> when there is a new version of the patch.
> >
> > Isn't the real problem here that there's no consensus
> On 1 Aug 2023, at 20:45, Robert Haas wrote:
>
> On Tue, Aug 1, 2023 at 2:24 PM Daniel Gustafsson wrote:
>> returned with feedback. Please feel free to resubmit to a future CF when
>> there
>> is a new version of the patch.
>
> Isn't the real problem here that there's no consensus on what
On Tue, Aug 1, 2023 at 2:24 PM Daniel Gustafsson wrote:
> returned with feedback. Please feel free to resubmit to a future CF when
> there
> is a new version of the patch.
Isn't the real problem here that there's no consensus on what to do?
Or to put a finer point on it, that Tom seems
> 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:
>
>>> I'm happy to bring back the control-file switch if there's an
>>> agreement about that.
>>
>> I'm attaching an
> On 31 May 2023, at 21:07, Sandro Santilli wrote:
> On Thu, Apr 27, 2023 at 12:49:57PM +0200, Sandro Santilli wrote:
>> I'm happy to bring back the control-file switch if there's an
>> agreement about that.
>
> I'm attaching an up-to-date version of the patch with the control-file
> switch
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 original suggestion (wildcard filenames
> >
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
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 opinion is fully contained in the from/to
range.
The name "ANY" should also
On Mon, May 1, 2023 at 11:05 PM Eric Ridge wrote:
>
> > We expect the .so's own minor version number to suffice for that,
> > but I realize that that might not be the most user-friendly answer.
>
> One of my desires is that the on-disk .so's filename be associated with
> the pg_extension entry
> It isn't. ZDB, and I think (at least) PostGIS, have their own "version()"
function.
> Keeping everything the same version keeps me "sane" and eliminates a class
> of round-trip questions with users.
>
Yes we have several version numbers and yes we too like to keep the
extension version the
> On May 1, 2023, at 4:24 PM, Tom Lane wrote:
>
> Eric Ridge writes:
>> FWIW, outside of major ZDB releases, most of those have little-to-zero
>> schema changes. But that doesn't negate the fact each release needs its own
>> upgrade.sql script. I'm working on a point release right this
Eric Ridge writes:
> FWIW, outside of major ZDB releases, most of those have little-to-zero schema
> changes. But that doesn't negate the fact each release needs its own
> upgrade.sql script. I'm working on a point release right this moment and it
> won't have any schema changes but it'll
> On May 1, 2023, at 12:12 PM, Robert Haas wrote:
>
> On Fri, Apr 28, 2023 at 10:03 AM Eric Ridge wrote:
>> ZomboDB has 137 releases over the past 8 years.
>
> Dang.
>
> This may be one of those cases where the slow pace of change for
> extensions shipped with PostgreSQL gives those of us
On Fri, Apr 28, 2023 at 10:03 AM Eric Ridge wrote:
> ZomboDB has 137 releases over the past 8 years.
Dang.
This may be one of those cases where the slow pace of change for
extensions shipped with PostgreSQL gives those of us who are
developers for PostgreSQL itself a sort of tunnel vision. The
(I'm the developer of ZomboDB and pgrx, which while not an extension per se,
allows others to make extensions that then need upgrade scripts. So this topic
is interesting to me.)
> On Mar 13, 2023, at 2:48 PM, Regina Obe wrote:
>
>>> I wonder if a solution to this problem might be to provide
>
> > As for Tom's concern about downgrades, I think it's valid but it's a
> > case that is easy to test for in Plpgsql and either handle or error.
> > For example, we use semver so testing for a downgrade at the top of
> > the upgrade script is trivial.
>
I was thinking about this more. The
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
> This change also makes it easier for extensions that use versioned .so files
> (by that I mean uses extension-.so rather than extension.so).
> Because such extensions can't really use the chaining property of the
> existing upgrade system and so need to write a direct X--Y.sql migration file
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.
Having one big upgrade file, at its core, enables you to do is move the
logic for "what
> Here are my thoughts of how this can work to satisfy our specific needs
and
> that of others who have many micro versions.
>
> 1) We define an additional file. I'll call this a paths file
>
> So for example postgis would have a
>
> postgis.paths file
>
> The format of the path file would be
Here are my thoughts of how this can work to satisfy our specific needs and
that of others who have many micro versions.
1) We define an additional file. I'll call this a paths file
So for example postgis would have a
postgis.paths file
The format of the path file would be of the form
, =>
> Personally I don't see the benefit of 1 big file vs. many 0-length files
to justify
> the cost (time and complexity) of a PostgreSQL change, with the
> corresponding cost of making use of this new functionality based on
> PostgreSQL version.
>
>From a packaging stand-point 1 big file is better
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
> Packager might actually know better in that they could ONLY consider the
> packages ever packaged by them.
>
I'm a special case packager cause I'm on the PostGIS project and I only
package postgis related extensions, but even I find this painful.
But for most packagers, I think they are
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
> 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
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
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
become static resources.
While I [intentionally] overlook some details
On Mon, Mar 13, 2023 at 02:48:56PM -0400, Regina Obe wrote:
>
> I still see the main use-case as for those that micro version and for this
> use case, they would need a way, not necessarily to have a single upgrade
> script, but a script for each minor.
>
> So something like
>
> 3.2.%--3.4.0 =
> > 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 (the extension authors) promise that if you
> > want
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
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
> 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 (the
> extension authors) promise that if you want to
On Wed, Mar 8, 2023 at 7:27 AM Sandro Santilli wrote:
> Now, PostGIS has released a total of 164 versions:
That is a LOT of versions. PostGIS must release really frequently, I guess?
> I guess you may suggest that we do NOT increas the *EXTENSION* version
> number UNLESS something really
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
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
> I'm not unsympathetic to the idea of trying to support multiple upgrade paths
> in one script. I just don't like this particular design for that, because it
> requires the extension author to make promises that nobody is actually going
> to deliver on.
>
> regards, tom
> The thing that confuses me here is why the PostGIS folks are ending up with
> so many files.
> We certainly don't have that problem with the extension that
> are being maintained in contrib, and I guess there is some difference in
> versioning practice that is making it an issue for them but
Robert Haas writes:
> On Tue, Jan 10, 2023 at 6:50 PM Tom Lane wrote:
>> As an example, suppose that a database has foo 4.0 installed, and
>> the DBA decides to try to downgrade to 3.0. With the system as it
>> stands, if you've provided foo--4.0--3.0.sql then the conversion
>> will go through,
On Tue, Jan 10, 2023 at 6:50 PM Tom Lane wrote:
> The script-file-per-upgrade-path aspect solves a problem that you
> have, whether you admit it or not; I think you simply aren't realizing
> that because you have not had to deal with the consequences of
> your proposed feature. Namely that you
On Mon, Mar 06, 2023 at 02:54:35PM -0500, Gregory Stark (as CFM) wrote:
> This patch too is conflicting on meson.build.
I'm attaching a rebased version to this email.
> Maybe it can just be solved with multiple one-line scripts
> that call to a master script?
Not really, as the problem we are
> This patch too is conflicting on meson.build. Are these two patches
> interdependent?
>
> This one looks a bit more controversial. I'm not sure if Tom has been
> convinced and I haven't seen anyone else speak up.
>
> Perhaps this needs a bit more discussion of other options to solve this
This patch too is conflicting on meson.build. Are these two patches
interdependent?
This one looks a bit more controversial. I'm not sure if Tom has been
convinced and I haven't seen anyone else speak up.
Perhaps this needs a bit more discussion of other options to solve
this issue. Maybe it can
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
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,
> Sandro Santilli writes:
> > On Mon, Jan 09, 2023 at 05:51:49PM -0500, Tom Lane wrote:
> >> ... 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 itself, but won't solve our problem.
>
Sandro Santilli writes:
> On Mon, Jan 09, 2023 at 05:51:49PM -0500, Tom Lane wrote:
>> ... 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 itself, but won't solve our problem.
The
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
> I continue to think that this is a fundamentally bad idea. It creates all
sorts of
> uncertainties about what is a valid update path and what is not.
Restrictions
> like
>
> + Such wildcard update
> + scripts will only be used when no explicit path is found from
> + old to target
I continue to think that this is a fundamentally bad idea. It creates
all sorts of uncertainties about what is a valid update path and what
is not. Restrictions like
+ Such wildcard update
+ scripts will only be used when no explicit path is found from
+ old to target version.
are
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
I reviewed this patch
On Wed, Nov 16, 2022 at 05:25:07PM -0600, Justin Pryzby wrote:
> Note that the patch is passing tests when using autoconf build but
> failing for meson builds.
Thanks for pointing me to the right direction.
I'm attaching an updated patch, will keep an eye on cirrusCI
--strk;
>From
Note that the patch is passing tests when using autoconf build but
failing for meson builds.
http://cfbot.cputube.org/sandro-santilli.html
I imagine you need to make the corresponding change to ./meson.build
that you made to ./Makefile.
https://wiki.postgresql.org/wiki/Meson_for_patch_authors
> 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 have a "wildcard_upgrades = true"
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 have a "wildcard_upgrades = true"
> 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 have a "wildcard_upgrades = true" statement.
> >
> > When wildcard upgrades are enabled, a file with a "%"
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 have a "wildcard_upgrades = true" statement.
>
> When wildcard upgrades are enabled, a file with a "%" symbol as
> the
Re: Tom Lane
> The existing logic to find multi-step upgrade paths is going to make
> this a very pressing problem. For example, if you provide both
> extension--%--2.0.sql and extension--%--2.1.sql, it's not at all
> clear whether the code would try to use both of those or just one
> to get from
Apologies. I made a mistake on my downgrade test.
So 3 should be
3) It is possible to downgrade with the wildcard. For example I had
paths
wildtest--%--2.1.sql
and confirmed it used the downgrade path when going from 2.2 to 2.1
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
PURPOSE:
This feature is intended to allow projects with
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 submit an updated
On Mon, Oct 31, 2022 at 01:55:05AM -0400, Regina Obe wrote:
>
> Sandro, can you submit an updated version of this patch.
> I was testing it out and looked good first time.
Attached updated version of the patch.
> If everyone is okay with this patch, we'll go ahead and add tests and
>
Just to reiterate the main impetus for this patch is to save PostGIS from
shipping 100s of duplicate extension files for each release.
> And now with the actual patch attached ... (sorry)
>
> --strk;
>
Sandro, can you submit an updated version of this patch.
I was testing it out and looked
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 doesn't have a
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 have a "wildcard_upgrades = true" statement.
When wildcard upgrades are enabled, a file with a "%" symbol as
the "source" part of the upgrade
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
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
> >
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
Laurenz Albe writes:
> 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.sql" and "extension--1.0--2.0.sql" present.
>Otherwise the behavior might be indeterministic.
The
> 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.sql" and "extension--1.0--2.0.sql" present.
> Otherwise the behavior might be
On Fri, 2022-05-27 at 17:37 -0400, Regina Obe wrote:
> > At PostGIS we've been thinking of ways to have better support, from
> > PostgreSQL proper, to our upgrade strategy, which has always consisted in a
> > SINGLE upgrade file good for upgrading from any older version.
> >
> > The current lack
> At PostGIS we've been thinking of ways to have better support, from
> PostgreSQL proper, to our upgrade strategy, which has always consisted in
a
> SINGLE upgrade file good for upgrading from any older version.
>
> The current lack of such support for EXTENSIONs forced us to install a lot
of
>
At PostGIS we've been thinking of ways to have better support, from
PostgreSQL proper, to our upgrade strategy, which has always consisted
in a SINGLE upgrade file good for upgrading from any older version.
The current lack of such support for EXTENSIONs forced us to install
a lot of files on
78 matches
Mail list logo
