[postgis-tickets] [PostGIS] #5166: Remove Micro (Patch level) from our extension scripts and use 0-byte scripts (was: Remove Micro (Patch level) from our extension scripts)

[PostGIS]

#5166: Remove Micro (Patch level) from our extension scripts and use 0-byte
scripts
------------------------------------+---------------------------
  Reporter:  robe                   |      Owner:  strk
      Type:  defect                 |     Status:  new
  Priority:  medium                 |  Milestone:  PostGIS 3.3.0
 Component:  build/upgrade/install  |    Version:  master
Resolution:                         |   Keywords:
------------------------------------+---------------------------
Changes (by robe):

 * summary:  Remove Micro (Patch level) from our extension scripts =>
     Remove Micro (Patch level) from our extension scripts and use 0-byte
     scripts


Old description:

> This will be for PostGIS 3.3.0 moving forward.  We discussed the idea of
> doing that for all minors, but decided that was too drastic.
>
> So sadly we've still got to carry all those scripts.
>
> 3.3 will have scripts
>
> {{{
> # these all 0 byte
>  postgis--3.0.0--3.3.X.sql
>  postgis--3.0.1--3.3.X.sql
>  :
>  postgis--3.1.0--3.3.X.sql
>  postgis--3.1.1--3.3.X.sql
>  postgis--3.1.2--3.3.X.sql
> :
> :
> postgis--3.2.1--3.3.X.sql
> postgis--3.3.0alpha1--3.3.X.sql
> postgis--3.3.0dev--3.3.X.sql
>
> # these not 0 byte
> postgis--3.3.X--3.3.sql
> postgis-3.3next--3.3.sql
> postgis-3.3--3.3next.sql
> }}}
>

>
> (the 3.3next 3.3.sql I am thinking if we decided we want our alter
> extension scripts to have CREATE OR REPLACE only for existing and CREATE
> for net-net new, we'd still keep the CREATE OR REPLACE for the 3.3next
> even for net-net new and for the 3.3X--3.3.sql this would be CREATE for
> net-net new functionality.
>
> and so most we will use 0 byte files as Paul proposed here -
> https://trac.osgeo.org/postgis/wiki/PostGISExtensionPaths#SOLUTION3
>
> postgis 3.4 would then look like
>
> {{{
> # these all 0 byte
>  postgis--3.0
>  :
>  postgis--3.1.0--3.4.X.sql
>  postgis--3.1.1--3.4.X.sql
>  postgis--3.1.2--3.4.X.sql
> :
> :
> postgis--3.2.1--3.4.X.sql
> postgis--3.3--3.4.X.sql #regardless which 3.3 micro release, no new files
>
> # these not 0 byte
> postgis--3.4.X--3.4.sql
> postgis-3.4next--3.4.sql
> postgis-3.4-3.4next.sql
> }}}

New description:

 This will be for PostGIS 3.3.0 moving forward.  We discussed the idea of
 doing that for all minors, but decided that was too drastic.

 So sadly we've still got to carry all those scripts.

 3.3 will have scripts

 {{{
 # these all 0 byte
  postgis--3.0.0--3.3.MAX.sql
  postgis--3.0.1--3.3.MAX.sql
  :
  postgis--3.1.0--3.3.MAX.sql
  postgis--3.1.1--3.3.MAX.sql
  postgis--3.1.2--3.3.MAX.sql
 :
 :
 postgis--3.2.1--3.3.MAX.sql
 postgis--3.3.0alpha1--3.3.MAX.sql
 postgis--3.3.0dev--3.3.MAX.sql

 # these not 0 byte
 postgis--3.3.MAX--3.3.sql
 postgis-3.3next--3.3.sql
 postgis-3.3--3.3next.sql
 }}}


 (the 3.3next 3.3.sql I am thinking if we decided we want our alter
 extension scripts to have CREATE OR REPLACE only for existing and CREATE
 for net-net new, we'd still keep the CREATE OR REPLACE for the 3.3next
 even for net-net new and for the 3.3X--3.3.sql this would be CREATE for
 net-net new functionality.

 and so most we will use 0 byte files as Paul proposed here -
 https://trac.osgeo.org/postgis/wiki/PostGISExtensionPaths#SOLUTION3

 postgis 3.4 would then look like

 {{{
 # these all 0 byte
  postgis--3.0.0--3.3.MAX.sql
  :
  postgis--3.1.0--3.4.MAX.sql
  postgis--3.1.1--3.4.MAX.sql
  postgis--3.1.2--3.4.MAX.sql
 :
 :
 postgis--3.2.1--3.4.MAX.sql
 postgis--3.3--3.4.MAX.sql #regardless which 3.3 micro release, no new
 files

 # these not 0 byte
 postgis--3.4.MAX--3.4.sql
 postgis-3.4next--3.4.sql
 postgis-3.4-3.4next.sql
 }}}

--
Comment:

 Replying to [comment:2 strk]:
 > Is there a typo in the original description of this ticket ? I don't
 understand the `postgis--3.0` line, and I see spaces before the
 `--3.4.X.sql` which I'm not sure how to interpret.
 >
 Yes
 > Also, I think Paul idea was to have upgrade scripts look like:
 >
 >  `postgis-3.1.1--3.1.MAX.sql' or similar ?
 >
 > I don't see the benefit of having an upgrade path called `3.3.X--3.3.0`
 otherwise (would look like being open for downgrades) ?

 Fixed
 >
 > How does this simplify things ? What problem does it solve ?

 It simplifies things because:

 1)  We will eventually have fewer files (savings of not having micro
 scripts moving forward)
 Note even if PostgreSQL project were to fix this, we'd still need
 something like this for older versions of PostgreSQL since they likely
 will not backport that.

 2) Using Paul's 0 byte, the file sizes will be smaller even if the
 packager doesn't symlink.
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5166#comment:4>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.