id summary reporter owner description type status priority milestone component version resolution keywords cc 1831 ability to separate user defined spatial_ref_sys from installed robe Bborie Park "I thought we had this in our tracker already, but perhaps we only discussed it. spatial_ref_sys is a semi-postgis / semi user-defined. We have been battling the issue of how to separate these two so that upgrade is a bit less painless for as far back as I can remember. It wasn't so much of an issue when we had fewer users but now is becoming more of a major one. 1) strk proposed a while back making it a view and having two tables: spatial_ref_sys_master, spatial_ref_sys_custom and then spatial_ref_sys would be the union of the 2 and people would put all their custom entries in spatial_ref_sys_custom 2) I didn't like that idea too much because it might break apps and proposed we just have a bit switch instead where we would tag all the ones we input is postgis installed. And the remaining ones we would default user input to true so in theory nothing would change except for people being lazy and doing an insert like INSERT INTO spatial_ref_sys VALUES (... without qualifying the tables. strk also pointed out it might break the postgis_restore which assumes the structure. 3) I have a third idea which is a bit of a morph of the two. Keep spatial_ref_sys as a table, but add another table for custom spatial ref_sys records. Have custom spatial_ref_sys inherit from spatial_ref_sys but put in a DO INSTEAD OF trigger in spatial_ref_sys that we would put in after we have inserted all our records. The do instead would push updates to the custom_spatial_ref_sys (It's really a revision of strk's #1) " enhancement closed medium PostGIS 3.0.0 postgis master wontfix