tickets.sql fail with --schema postgis (UpdateGeometrySRID?)

[strk]

Running this:

regress/run_test.pl --schema postgis -v regress/core/tickets.sql

Fail as follows:

 regress/core/tickets .. failed (diff expected obtained: /tmp/pgis_reg/test_1_diff)
-----------------------------------------------------------------------------
--- regress/core/tickets_expected       2019-08-26 14:00:15.408731758 +0200
+++ /tmp/pgis_reg/test_1_out    2019-10-18 17:17:23.518001330 +0200
@@ -198,13 +198,12 @@
 ERROR:  transform: tolerance condition error (-20)
 #1580.3|Point[S]
 #1596.1|public.road_pg.roads_geom SRID:3395 TYPE:POINT DIMS:2 
-ERROR:  invalid SRID: 330000 not found in spatial_ref_sys
+ERROR:  column not found in geometry_columns table
 #1596.3|3395
-ERROR:  invalid SRID: 999000 not found in spatial_ref_sys
+ERROR:  column not found in geometry_columns table
 #1596.5|3395
-NOTICE:  SRID value -1 converted to the officially unknown SRID value 0
-#1596.6|public.road_pg.roads_geom SRID changed to 0
-#1596.7|0
+ERROR:  column not found in geometry_columns table
+#1596.7|3395
 #1596|Point[GS]
 #1695|MULTIPOLYGON EMPTY
 #1697.1|0
-----------------------------------------------------------------------------

It looks like there's some wrong assumption in UpdateGeometrySRID

[strk]

Note that the bug only occurs when NOT running in EXTENSION mode (just add —extension to the run and the test will pass)

[strk]

Here's the problem:

postgis_reg=# select * from postgis.geometry_columns;
 f_table_catalog | f_table_schema | f_table_name | f_geometry_column | coord_dimension | srid | type  
-----------------+----------------+--------------+-------------------+-----------------+------+-------
 postgis_reg     | public         | road_pg      | roads_geom        |               2 | 3395 | POINT
(1 row)

postgis_reg=# SELECT '#1596.2', postgis.UpdateGeometrySRID( '','','road_pg','roads_geom', 330000);
ERROR:  column not found in geometry_columns table
CONTEXT:  PL/pgSQL function updategeometrysrid(character varying,character varying,character varying,character varying,integer) line 35 at RAISE

The search_path in the session issuing the above is just "public".

[strk]

Right now, in non-extension mode, we're just _omitting_ the @schema@ placeholder used in function bodies. Instead we'd need a way to still use it somehow.

For other projects I've been using a wrapper script to load the SQL, and doing the search&replace portions, but for us it would mean yet another way to install PostGIS which makes things more complex.

Can we think of a way to instead somehow wrap the full SQL into some plpgsql doing an execute regexp_replace ? Regina I know you'll like the idea !