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

[Regina Obe]

But you are okay with 0 byte files as Paul proposed right?  That wouldn’t change functionality.  Just changing symlink to 0 byte.  I don’t know about any other systems or how people package but packaging symlinks doesn’t work well on windows.

 

For PostGIS 3.3.0 my package size doubled because we now have the spatial_ref_sys.sql files included in every micro.

 

So I guess size is more important to me now as it is causing me to run out of disk space faster.

 

Thanks,

Regina

 

 

 

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of ??????? ?????????????
Sent: Monday, June 6, 2022 10:10 AM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [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 <mailto: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 <mailto: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/fe9adac2/attachment-0001.htm>