User-defined SRIDs are not working after Postgis 3.3.2 to 3.5.3 update

[Alexander Trufanov]

> Did you run
> SELECT postgis_extensions_upgrade();

Yes. It prints "Upgrade to version 3.5.3 completed, run SELECT
postgis_full_version(); for details"

But this doesn't help.

SELECT postgis_full_version(); prints:

"POSTGIS="3.5.3 aab5f55" [EXTENSION] PGSQL="150" GEOS="3.11.1-CAPI-1.17.1"
PROJ="9.1.1 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org
USER_WRITABLE_DIRECTORY=/tmp/proj DATABASE_PATH=/usr/share/proj/proj.db"
(compiled against PROJ 9.1.1) GDAL="GDAL 3.6.2, released 2023/01/02"
LIBXML="2.9.14" LIBJSON="0.16" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)"
RASTER"

>Can you please check which namespaces PostGIS finds with these two
queries:
> SELECT extnamespace::regnamespace FROM pg_extension WHERE extname =
'postgis';
> SELECT pronamespace::regnamespace FROM pg_proc WHERE proname =
'postgis_full_version';

Both return "public".

The full result record from pg_extension is
https://pastebin.com/raw/6mwrGhmH
For pg_proc it's: https://pastebin.com/a4pTVs9U







пт, 25 июл. 2025 г. в 16:43, James Klassen <klassen.js at gmail.com>:

> Did you run
>
> SELECT postgis_extensions_upgrade();
>
> ?
>
>
> https://postgis.net/workshops/postgis-intro/upgrades.html#upgrading-postgis
>
>
> On Fri, Jul 25, 2025 at 08:18 Alexander Trufanov <trufanovan at gmail.com>
> wrote:
>
>> UPD. Just noticed that
>> SELECT ST_Transform('SRID=4326;POINT(0 0)'::geometry, 2000)
>> doesn't work either.
>> So it's not about user defined srids. The error happens at any access to
>> public.spatial_ref_sys
>>
>> пт, 25 июл. 2025 г. в 16:08, Alexander Trufanov <trufanovan at gmail.com>:
>>
>>> Hello,
>>>
>>> I have a Debian Bookworm-based system with Postgresql 15 and PostGis
>>> 3.3.2 on it.
>>> It works well, but recently I was faced with a requirement to use
>>> ST_Clip() function with touching argument support. Thus I need PostGis
>>> 3.5.x+.
>>>
>>> There was no PostGis newer than 3.3.2 in the official repos, but I
>>> managed to installed it with
>>>
>>> ```
>>>
>>> sudo apt install -y postgresql-common
>>> sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh bookworm
>>>
>>> sudo apt install postgis=3.5* postgresql-15-postgis-3=3.5*
>>> postgresql-15-postgis-3-scripts=3.5*
>>> ```
>>>
>>> Then I updated my Postgis extension.
>>>
>>> And now I'm facing an unexpectable problem. All my stored procedures are
>>> working fine unless they are trying to use user-defined SRIDs from the
>>> public.spatial_ref_sys. If so, they fail with following error message:
>>>
>>> "ERROR: Unable to determine 'postgis' install schema
>>> SQL state: XX000"
>>>
>>> For example, this works:
>>> SELECT ST_Transform('SRID=4326;POINT(0 0)'::geometry, 4326)
>>> and this is not:
>>> SELECT ST_Transform('SRID=4326;POINT(0 0)'::geometry, 100100)
>>>
>>> My 100100 srid record is:
>>> select * from public.spatial_ref_sys where srid = 100100
>>> 100100, '', 1, 'GEOGCS["WGS 84",    DATUM["WGS_1984",
>>>  SPHEROID["WGS 84",6378137,298.257223563,
>>>  AUTHORITY["EPSG","7030"]],        AUTHORITY["EPSG","6326"]],
>>>  PRIMEM["Greenwich",0],    UNIT["degree",0.0174532925199433],
>>>  AUTHORITY["EPSG","4326"]]', '+proj=longlat +datum=WGS84 +no_defs'
>>>
>>> I was trying to update this record in the table in case there is some
>>> trigger that should register it  in some new cache or config - but it does
>>> not help.
>>>
>>> Is there any cache or something else  to clean in public.spatial_ref_sys
>>> for postgis 4.5.3?
>>> Maybe user-defined srids should now be registered in another way?
>>>
>>> Also the error message "Unable to determine 'postgis' install schema  "
>>> is quite confusing.
>>>
>>> --
>>> With best regards,
>>> Alexander Trufanov
>>>
>>
>>
>> --
>> With best regards,
>> Alexander Trufanov
>>
>

-- 
With best regards,
Alexander Trufanov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20250725/4236b03e/attachment.htm>