[postgis-devel] PSC Vote: Get rid of micro in PostGIS Extension scripts (and comments from others)

[Дорофей Пролесковский]

-1 from me.

Forbidding to change SQL in micro is not a practice that we have
now, unlike the version drop from a .so where the symlink practice was
there for a while.

Extension files are not really a problem for end users now. It only looks
awful when you look inside, not use.
It brings pain to developers (no way to change the SQL in micro) to ease
the pain of computers (hundred files on FS).

The solution will be partial - the old files won't go away just because of
it.

If we're going to do something about it I believe it should be a thing
bringing the version model closer to the Postgres intended one, where diffs
are being generated or scripts are getting constructed in form of a
DAG/chain of version migrations. This can also help fix the issue of extra
features in newer PG for the same PostGIS, if we bake the PG version into
the extension version - which differs really between PG versions.

Maybe what we need is a bit more indirection on the PG side - if we can
have a table that lists all the upgrade scripts and the version pair will
be a part of the table and filename can be arbitrary - then there won't be
a problem of duplicated files on the filesystem. Maybe a way to register
aliases as not to break the currently working way.

A thing to look at: Postgres now has stored procedures that exist outside
transactions, may happen that calling one will fix the problem with running
postgis_extensions_upgrade() - we can do that twice internally.




пт, 3 июн. 2022 г. в 16:31, Regina Obe <lr at pcorp.us>:

> Given this is not a trivial decision, I want to make sure no one has
> reservations that can't be addressed.
> That includes non-PSC.
>
> +1 from me.
>
> Detailed here (sorry I had the subject part wrong initially)
>
> https://trac.osgeo.org/postgis/ticket/5166
>
> This will be for PostGIS 3.3.0 onward (we'd still need to track all those
> old files from previous versions, annoying)
>
> Benefits:
>
> 1) Fewer extension files piling up moving forward
> 2) Not having this annoyance of remembering to add the latest micro (at
> least for 3.3, will be useful for 3.4) moving forward.
>
> Cons:
> 1) Doing micro SQL API changes will be harder, and so should be avoided. We
> don't do that many of those anyway aside from security patches.
> 2) Nothing will happen if people do
>
> ALTER EXTENSION postgis UPDATE;
>
> If they are already on latest minor.  We've had this issue all along by the
> way (even for micros)  for cases where people pg_upgrade from say 3.2.1 on
> PG 11 to 3.2.1 on PG 14, because extension system doesn't recognize the
> idea
> that a particular extension version might have extra features enabled for
> newer versions of PostgreSQL.
>
> However I think this can all be mitigated, for folks trained to use:
>
> SELECT postgis_extensions_upgrade();
>
> strk -- I haven't checked, but I think you had changed this to work if the
> PostgreSQL version script is different from the current PostgreSQL version.
> If not we need to fix that anyway.
>
> We could also add a force or an explicit PostGIS version arg to that which
> we would need for development upgrades and when such a version is passed it
> will force upgrade using next or ANY hack.
>
> The force way should avoid touching system tables, since DBaaS won't allow
> it, but I think doing a yoyo dance (next -> back to where we were) works
> fine.
>
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20220606/2ffd7121/attachment.htm>