public inbox for [email protected]
help / color / mirror / Atom feedFrom: Regina Obe <[email protected]>
To: [email protected]
Cc: 'Yurii Rashkovskii' <[email protected]>
Cc: 'Tom Lane' <[email protected]>
Cc: 'Regina Obe' <[email protected]>
Cc: [email protected]
Subject: RE: [PATCH] Support % wildcard in extension upgrade filenames
Date: Thu, 13 Apr 2023 18:32:55 -0400
Message-ID: <[email protected]> (raw)
References: <YgakFklJyM5pNdt+@c19>
<20221117095734.igldlk6kngr6ogim@c19>
<166914379479.1121.7549798686571352890.pgcf@coridan.postgresql.org>
<[email protected]>
<CA+RLCQwWpMuKtqg7eBOjvzpJc-hE708WpHG2=z5B969xncQS3w@mail.gmail.com>
<20230409204629.sf4fptx672iehcau@c19>
<[email protected]>
<20230411184823.s3cctaf63qvfeqlj@c19>
<[email protected]>
<20230411212737.phtzffycglbdhmpx@c19>
> 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
>
> <version pattern1>,<version pattern2> => 3.3.0--3.4.0
>
> It will also allow a wildcard option
> % => ANY--3.4.0.sql
>
> So a postgis.paths with multiple lines might look like
>
> 3.2.0,3.2.1 => 3.2.2--3.3.0
> 3.3.% => 3.3--3.4.0
> % => ANY--3.4.0
>
> 2) The order of precedence would be:
>
> a) physical files are always used first
> b) If no physical path is present on disk, then it looks at a
<component>.paths
> file to formulate virtual paths
> c) Longer mappings are preferred over shorter mappings
>
> So that means the % => ANY--3.4.0 would be the path of last resort
>
> Let's say our current installed version of postgis is postgis VERSION
3.2.0
>
> The above path formulated would be
>
> 3.2.0 -> 3.3.0 -> 3.4.0
> The simulated scripts used to get there would be
>
> postgis--3.2.2--3.3.0.sql
> postgis--3.3.0--3.4.0.sql
>
>
> This however does not solve the issue of downgrades, which admittedly
> postgis is not concerned about since we have accounted for that in our
> internal scripts.
>
> So we might have issue with having a bear: %. If we don't allow a bear %
>
> Then our postgis patterns might look something like:
>
> 3.%, 2.% => ANY --3.4.0
>
> Which would mean 3.0.1, 3.0.2, 3.2.etc would all use the same script.
>
> Which would still be a major improvement from what we have today and
> minimizes likeliness of downgrade footguns.
>
> Thoughts anyone?
>
Minor correction scripts to get from 3.2.0 to 3.4.0 would be:
postgis--3.2.2--3.3.0.sql
postgis--3.3--3.4.0.sql
view thread (21+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: RE: [PATCH] Support % wildcard in extension upgrade filenames
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox