pg_upgrade fails due to lack of dependencies.

[Regina Obe]

> You said above that your users are usually smart enough to deal with
> problems like that.  In that case, your users must be way smarter than the
> average PostgreSQL user.
> 

Not our average users, our users that use ST_Transform in their indexes and computed columns or that use srid other than 4326 for their geography data.
I would say 99% of our users don't do any of the above.  Heck I've never had a need to use an srid other than 4326 for geography data and since 4326 is the default, it is never checked against spatial_ref_sys so has no dependency on that table.

Such configs are rare especially not with passive users of PostGIS.


> The idea of manually fiddling with pg_depend scares even me.
> 

It scares me too and scares me more adding this to PostGIS code base to address issues I feel are only experienced by very few users.
I even like it less if it still requires shuffling your pg_upgrade to restore data in the right order.


> The place where I'd look if I wanted to upgrade my spatial database would be
> https://postgis.net/docs/manual-3.5/postgis_administration.html#upgrading
> 
> Perhaps it would be a good idea to mention there that an upgrade using
> pg_upgrade is likely to fail if you are using functions that rely on SRID
> definitions in indexes, generated columns or partitioning keys.
> 
> Yours,
> Laurenz Albe

Yes agree, we should document this as an issue, and say if you must,
Read this FAQ article similar to the pain we had to detail with people upgrading from PostGIS 2+ to 3+ and that are using raster.