[SCM] postgis.net branch website updated. clarity-final-224-gdb8ccba

Thu Jul 30 06:59:28 PDT 2026

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "postgis.net".

The branch, website has been updated
       via  db8ccba2854c8ae17f89a55668f98b20c8545bcb (commit)
       via  f956ce25f20db2e3216740aae55edfb0b323413b (commit)
      from  27427675fdcbad5b22bf6d3cc600d932913cb096 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit db8ccba2854c8ae17f89a55668f98b20c8545bcb
Merge: 2742767 f956ce2
Author: Darafei Praliaskouski <komzpa at gmail.com>
Date:   Thu Jul 30 06:59:27 2026 -0700

    Merge pull request 'Move Trac RFC 6 and 7 onto website' (!20) from Komzpa/postgis.net:ai/trac-rfc67-20260730 into website
    
    Reviewed-on: https://gitea.osgeo.org/postgis/postgis.net/pulls/20


commit f956ce25f20db2e3216740aae55edfb0b323413b
Author: Darafei Praliaskouski <me at komzpa.net>
Date:   Thu Jul 30 17:14:28 2026 +0400

    Move Trac RFC 6 and 7 onto website

diff --git a/content/development/rfcs/rfc06.md b/content/development/rfcs/rfc06.md
new file mode 100644
index 0000000..6e6f905
--- /dev/null
+++ b/content/development/rfcs/rfc06.md
@@ -0,0 +1,43 @@
+---
+title: "RFC-6: Move to GIT"
+author: Regina Obe
+version: 1.0
+category: rfcs
+date: "2019-10-27"
+draft: false
+type: rfc
+relatedInSidebar: false
+singlecolumn: true
+sidebar: false
+geekdocHidden: true
+geekdocHiddenTocTree: false
+---
+
+| Field | Value |
+| --- | --- |
+| Date | 2019/10/27 |
+| Author | Regina Obe |
+| Last Edited | 2019/10/27 |
+| Last Updated By | Regina Obe \<lr at pcorp dot us\> |
+| Status | Approved |
+
+As noted on <https://lists.osgeo.org/pipermail/postgis-devel/2019-October/028199.html> and <https://lists.osgeo.org/pipermail/postgis-devel/2019-October/028184.html> we all voted to move to Git and have Gitea as our master Git repo.
+We will still have a git mirror on github and gitlab and allow pull requests on github, gitlab, and gitea.
+Trac will still be our issue tracker for now and repointed to GIT.
+
+Regina Obe and Sandro Santilli will be responsible for the move.
+
+This document is to outline the steps we'll be doing to move from SVN to git.
+
+* Upgrade gitea to latest 1.9.4 (done)
+* Upgrade trac to latest 1.4 (in progess - have upgraded on <https://dev.trac.osgeo.org/postgis> to test to see if any issues)
+  * Markus Neteler noticed the SectionEditor Plugin is missing in 1.4 which is something most of our trac instances use. He said would be nice to have it but we could try to patch or live without it.
+  * Verify Email notifications are working in new trac version
+* Change all the svn references in trac tickets to corresponding git references
+* Change trac repo pointing to git repo instead of svn repo [done]
+* Restrict access to SVN [done]
+* Change mirroring from svn-git to git-git (with github and gitlab mirroring from gitea) [done]
+* Move git mirroring logic to an osgeo server (from strk's personal computer or possibly set up as gitlab pulls from gitea and feeds to github)
+* Make sure debbie and winnie have their master switched to master (from svn-trunk) [done]
+* Upgrade dronie (new version has cancel obsolete trees)
+* Update [Committer Guidelines](/development/rfcs/rfc05/)
diff --git a/content/development/rfcs/rfc07.md b/content/development/rfcs/rfc07.md
new file mode 100644
index 0000000..fbe0b14
--- /dev/null
+++ b/content/development/rfcs/rfc07.md
@@ -0,0 +1,118 @@
+---
+title: "RFC-7: Managing PostGIS Extension Paths with Fewer and or smaller Files"
+author: Regina Obe
+version: 1.0
+category: rfcs
+date: "2022-02-11"
+draft: false
+type: rfc
+relatedInSidebar: false
+singlecolumn: true
+sidebar: false
+geekdocHidden: true
+geekdocHiddenTocTree: false
+---
+
+| Field | Value |
+| --- | --- |
+| Date | 2022/02/11 |
+| Author | Regina Obe |
+| Last Edited | 2022/02/11 |
+| Last Updated By | Regina Obe \<lr at pcorp dot us\> |
+| Status | In Discussion |
+
+## Problem Statement
+
+With each new version of PostGIS, we need to ship more and more extension upgrade scripts.
+In reality all the upgrade scripts are just a symlink to the main one or exact copies of the main one.
+This results in a users extensions folder cluttered with 100s or more of PostGIS related scripts.
+
+Not only that, but for each new version we ship, we always need to remember to add the recently shipped micros of other versions
+to the extensions/updateable.mk script.
+
+In addition, the large and changing set of files imposes work (and thus the possibility of errors) on some packaging systems, which have a manifest of installed files. While maintaining this for files that should exist is fine -- and allows detecting new/removed files at update time that can be checked against NEWS -- dealing with upgrade scripts has been a significant amount of the ugprade work in pkgsrc.
+
+The largeness of the script files (when not symlinked, which is often the case), is the biggest issue of all, and will become even more of an issue
+with shipping spatial_ref_sys updates.
+
+The solution of the above issues is to have: Solution 1, Solution 2, and Solution 3 implemented, as some solutions are not backward compatible but do provide extra benefits.
+
+## Solution 1 (Fails)
+
+This has already been committed in master branch for PostGIS 3.3.0.
+Embedded in:
+
+```sql
+SELECT postgis_extensions_upgrade();
+```
+
+What it does:
+Update the current version to ANY and then run the updates.
+This has the affect of always forcing the postgis--ANY--
+
+BLOCKER: this solution does not work in some cloud environments, see <https://trac.osgeo.org/postgis/ticket/5194>
+
+## Solution 2
+
+[Beg and plea upstream](https://www.postgresql.org/message-id/YgakFklJyM5pNdt%2B%40c19) to recognize a % or ANY as a first class citizen to mean any prior version.
+
+This approach allows for defining a new line item in the control file, that denotes something like
+
+```text
+upgrade_script_pattern = %--<version>
+```
+
+Where the % will be treated as a wildcard to match to provider the best match.
+
+**Benefits of this approach:**
+
+1. We have made what we are doing, built into the PostgreSQL machinery, so no special care needs to be done by packagers or users.
+It makes us not a special snowflake.
+
+2. It will help other extensions which have similar issues and just want a single upgrade script. We expect many extensions to benefit, though we will benefit the most.
+
+**Drawbacks:**
+
+1. Old PostgreSQL versions, won't understand this new world order, so we still need to maintain a backward compatible way for 5 years or more.
+
+## Solution 3
+
+The 0-byte file model. This approach creates 0 or very small byte files, with their existence solely to maintain PostgreSQL extension chain model.
+
+In this model, our generated extension upgrade scripts will look like the below, with only the postgis--3.3.X--3.3.0.sql having any upgrade statements in it and the others being 0-byte or miniscule with a comment or no-op command.
+
+```text
+:
+postgis--3.0.0--3.3.X.sql
+postgis--3.0.1--3.3.X.sql
+postgis--3.0.2--3.3.X.sql
+postgis--3.0.3--3.3.X.sql
+postgis--3.0.4--3.3.X.sql
+postgis--3.0.5--3.3.X.sql
+postgis--3.1.1--3.3.X.sql
+postgis--3.1.2--3.3.X.sql
+postgis--3.1.3--3.3.X.sql
+postgis--3.1.4--3.3.X.sql
+postgis--3.1.5--3.3.X.sql
+postgis--3.2.0--3.3.X.sql
+postgis--3.2.1--3.3.X.sql
+postgis--3.3.X--3.3.0.sql
+```
+
+**Benefits of this approach:**
+
+1. We are staying between the lines. Respecting known practices, but still having much lighter weight scripts.
+2. No change in upgrade extension workflow for packagers (or users who think of PostGIS as any other extension).
+3. It will work for all PostgreSQL versions supported
+
+**Downsides:**
+
+1. We still have the same useless clutter of files.
+
+2. It is not possible to upgrade from version (prior PostgreSQL version) 3.3.0 to (newer PostgreSQL version) 3.3.0 which is needed often in pg_upgrade to gain the benefits of new features in latest PostgreSQL version that are not exposed in older PostgreSQL versions. Such operation would just state "You are already at latest version" and not do anything, unless one does it via
+
+```sql
+SELECT postgis_extensions_upgrade();
+```
+
+which would have SOLUTION 1.

-----------------------------------------------------------------------

Summary of changes:
 content/development/rfcs/rfc06.md |  43 ++++++++++++++
 content/development/rfcs/rfc07.md | 118 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 161 insertions(+)
 create mode 100644 content/development/rfcs/rfc06.md
 create mode 100644 content/development/rfcs/rfc07.md


hooks/post-receive
-- 
postgis.net
