On Wed, Mar 16, 2022 at 09:20:10AM -0400, Greg Troxel wrote: > Sandro Santilli <s...@kbt.io> writes: > > > Another solution proposed was to still keep a single table but NEVER > > automatically upgrade it, providing a function to select "system > > entries" to use for populating the single table, when needed. > > With that, you don't get fixes to system values on upgrade, and I don't > see a way to merge them.
You don't get them automatically, but you can refresh to the system values by DELETEing your entries and INSERTing the ones from the system function. In the other solution (the 2 tables) you'd only need to DELETE the shadowing entries you don't need anymore. > Overall, if someone wants a different/extra value then it feels like one > of two cases: > > there is a bug in the postgis data (and a bug in EPSG), and it should > be fixed upstream, and it's workaround until then > > they are doing something local not appropriate for upstream, because > it is a local CRS, or its a wrong thing to counteract some other local > problem as a workaround, etc. > > So it would be extra cool if there were a way to say "print out local > shadowing entries that are not actually different from upstream" so > there's a nice path to recovering from the local entry after the bug is > fixed. In my 2-tables branch I had automatic cleanup of matching entries on upgrade, so you'd always only have different-from-upstream entries in the user (shadowing) table. And those shadowing entries would be reported by postgis_full_version(). --strk; _______________________________________________ postgis-users mailing list postgis-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/postgis-users