<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 3:03 AM 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">> > 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.<br></blockquote><div><br></div><div>Not exactly.</div><div><br></div><div>While it's true that objects are initially considered for dumping in alphabetical order, as mentioned earlier, <code>pg_dump</code> is smart enough to analyze <code>pg_depend</code> and reorder dependent objects to ensure they are dumped and restored in the correct order.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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 😊<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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.<br>
<br>
</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>