[postgis-tickets] [PostGIS] #4405: Index over ST_Transform(constant, SRID) breaks pg_upgrade

[PostGIS]

#4405: Index over ST_Transform(constant, SRID) breaks pg_upgrade
------------------------------------+-----------------------------
  Reporter:  Algunenano             |      Owner:  Algunenano
      Type:  defect                 |     Status:  closed
  Priority:  medium                 |  Milestone:  PostGIS Fund Me
 Component:  build/upgrade/install  |    Version:  master
Resolution:  wontfix                |   Keywords:
------------------------------------+-----------------------------

Comment (by robe):

 Replying to [comment:10 strk]:
 > Is this due to spatial_ref_sys contents NOT being visible at the time
 the table using the index is created ?

 Yes - NOT having data is the issue for pg_upgrade.

 The issue is when pg_upgrade runs I think it restores all the structures
 first and the data later but for some reason it restores the indexes
 before the data.  I think I complained about this on pg-hackers (thought I
 forget). The assumption is since all functions used in indexes are
 immutable, they should not rely on data in any tables. AS such it
 shouldn't matter the order you load the tables.  In this case other tables
 get loaded first and fail the index check because the spatial_ref_sys
 table is empty.  Actually I don't even think a table has to have data for
 it to fail the index check cause the index goes to check on the function
 it relies on to index empty data (I could be mistaken here).

 Why they can't create indexes after loading data I don't understand.
 Perhaps because it might slow the build of materialized views. Have no
 clue.

 I would think if they just changed the order of how they do things it
 would be fine.

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4405#comment:12>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.