<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Jul 2, 2025 at 8:20 PM Regina Obe <<a href="mailto:lr@pcorp.us">lr@pcorp.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-6120940269596229908"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_-6120940269596229908WordSection1"><p class="MsoNormal">Jeevan,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">So you are saying adding a dependency of spatial_ref_sys for geometry and geography should be sufficient to have the spatial_ref_sys data loaded for those before any user data with said columns?</p></div></div></div></blockquote><div><br></div><div>No. Data won't be loaded at that point by just adding dependencies.</div><div><br></div><div>However, the  spatial_ref_sys  table will be forced to dump (CREATE TABLE) ahead of geography and geography types if there are dependencies present in the pg_depend.</div><div><br></div><div>This will get rid of the upgrade errors that complain </div><div>"<span style="font-family:monospace">ERROR:  relation "public.spatial_ref_sys" does not exist</span>".</div><div><br></div><div>---</div><div><br></div><div>Somehow we managed to dump the data immediately after its creation for our customer (as a workaround). Fixing that at the PostGIS side might be difficult (might be doable at the Postgres side). But this dependency issue can only be fixed at the PostGIS side.</div><div><br></div><div>Thanks</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-6120940269596229908"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_-6120940269596229908WordSection1"><p class="MsoNormal"><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I can’t think of a case where ST_Transform would be used in a table definition where there wouldn’t be a geometry/geography column definition nearby.  So I suppose we can put in PostGIS 3.6.<u></u><u></u></p><p class="MsoNormal">I wouldn’t want to backport it without extensive testing though.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt"><div><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> Jeevan Chalke <<a href="mailto:jeevan.chalke@enterprisedb.com" target="_blank">jeevan.chalke@enterprisedb.com</a>> <br><b>Sent:</b> Wednesday, July 2, 2025 5:01 AM<br><b>To:</b> Regina Obe <<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>><br><b>Cc:</b> Laurenz Albe <<a href="mailto:laurenz.albe@cybertec.at" target="_blank">laurenz.albe@cybertec.at</a>>; Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>>; PostGIS Development Discussion <<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a>><br><b>Subject:</b> Re: pg_upgrade fails due to lack of dependencies.<u></u><u></u></span></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Wed, Jul 2, 2025 at 3:03<span style="font-family:Arial,sans-serif"> </span>AM Regina Obe <<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>> wrote:<u></u><u></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal">> > Yes that's a no go for 2 reasons<br>> ><br>> > 1) As you saw with the example mentioned, many people build indexes etc<br>> >    around this function.  If it were marked stable it would prevent usage<br>> >    in indexes etc.  The medicine would be way worse than the sickness.<br>> <br>> Even if the sickness is index corruption and inability to upgrade and restore a<br>> dump?<br>> <br><br>YES.  It's only pg_upgrade people have issues with cause it doesn't load all extension objects first like regular restores do. If you can't restore these with pg_upgrade, just restore them the old fashioned way.<br>Changing the functions to stable, means people can't create such indexes in the first place or use ST_Transform in their computed columns.<br>So it's the same as saying "If you don't want to feel pain, don't do that" vs. "We just won't let you do that"<br><br>Usually people that do these kinds of things are fairly clever, they are smart enough to find a way out of it without us snatching the gun from their hand and they'll scream if we try to grab their footgun from them.<br><br><br><br>> > 2) We tried making it stable like 10 years ago, and that made the function<br>> >    super unbearably slow.  Maybe things have changed since then, but the<br>> >    case 1 is still an issue.<br>> <br>> Could that have been problems around inlining that git solved with optimizer<br>> support functions in v12?<br><br>We could revisit to see that - could be.<br>> <br>> > > However, that dependency does not extend to the data in<br>> > > "spatial_ref_sys", so using the function in a generated column is still a<br>> problem.<br>> ><br>> > Yap my main concern.  But in case of pg_upgrade, since the data is<br>> > overlaid, at what point does it record, there is data in spatial_ref_sys?<br>> <br>> I didn't scrutinize the code, but the table data seem to get dumped in<br>> alphabetical order of "schemaname.tablename".<br>> <br><br>Okay so then a dependency wouldn't be guaranteed to help them.<u></u><u></u></p></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Not exactly.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">While it's true that objects are initially considered for dumping in alphabetical order, as mentioned earlier, <code><span style="font-size:10pt">pg_dump</span></code> is smart enough to analyze <code><span style="font-size:10pt">pg_depend</span></code> and reorder dependent objects to ensure they are dumped and restored in the correct order.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal">A simpler solution would be install postgis in a dedicated schema like I always tell people to do. In addition make sure that schema is alphabetically ahead of user data <span style="font-family:"Segoe UI Emoji",sans-serif">😊</span><u></u><u></u></p></blockquote><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal" style="margin-bottom:12pt"><br><br>> > The other discussion we had had, which I know Paul wants to throw up<br>> > everytime I mention it is to get rid of spatial_ref_sys and read<br>> > directly from the proj.db sqlite db that has the definitions.<br>> > Most of the time postgis just uses the proj.db def anyway.<br>> <br>> How IMMUTABLE is that?<br>> <br><br>For most users it's pretty IMMUTABLE but could change with proj upgrades, but it really doesn't matter is spatial_ref_sys is there or not<br>cause ultimately if the definition of an srid is in that proj.db that is what will be used.  Since proj.db is a separate file altogether, not part of PostgreSQL<br>it won't be screwed up by pg_upgrade not finding data.  Probably the same story as your collations/fulltext dictionaries etc.<br><br>I think Paul had issue with <br><br>Sometimes people want to make changes, and they have no access to file system if they are on DbaaS<br><br>Proj itself does have a mechanism of users keeping their own custom projections separate from the ones proj ships but that feature probably isn't available if you are on a DbaaS<br>Which a large majority of users are these days.<u></u><u></u></p></blockquote></div><div><p class="MsoNormal"><br clear="all"><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal"><span class="m_-6120940269596229908gmailsignatureprefix">-- </span><u></u><u></u></p><div><div><div><div><div><div><div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><img border="0" width="200" height="37" style="width: 2.0833in; height: 0.3854in;" id="m_-6120940269596229908_x0000_i1025" src="https://ci3.googleusercontent.com/mail-sig/AIorK4wUmLsFZCrsP0IzlqcrOBS4LG-QdOAM_CPz15Rip0P4elztKb7pS0FF_Tbb_lCOORByN9lcXUTXqe-8"><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><b>Jeevan Chalke</b><br><i><span style="font-family:Arial,sans-serif;color:rgb(29,28,29)">Principal Engineer, Engineering Manager</span><br>Product Development</i><br><b><span style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(255,62,0);background:white"><br><a href="https://www.enterprisedb.com" target="_blank">enterprisedb.com</a></span></b><u></u><u></u></p></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br></div><div dir="ltr"><img width="200" height="37" src="https://ci3.googleusercontent.com/mail-sig/AIorK4wUmLsFZCrsP0IzlqcrOBS4LG-QdOAM_CPz15Rip0P4elztKb7pS0FF_Tbb_lCOORByN9lcXUTXqe-8"><br></div><div dir="ltr"><br></div><div dir="ltr"><b>Jeevan Chalke</b><br><span style="color:rgb(29,28,29);font-family:Slack-Lato,Slack-Fractions,appleLogo,sans-serif"><i>Principal Engineer, Engineering Manager</i></span><i><br>Product Development</i><br><span style="font-size:11pt;font-family:Arial;color:rgb(255,62,0);background-color:rgb(255,255,255);font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br><a href="https://www.enterprisedb.com" target="_blank">enterprisedb.com</a></span></div></div></div></div></div></div></div></div></div>