From cedric.duprez at ign.fr Thu Jan 8 08:20:58 2026 From: cedric.duprez at ign.fr (Cedric Duprez) Date: Thu, 8 Jan 2026 17:20:58 +0100 Subject: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry Message-ID: <32e1df4b-dfbd-4a95-9271-98b3cd06cebe@ign.fr> Hi all, I'm facing a potential bug with PostGIS 3.6.1 on PostgreSQL 17.7. Here is what I get with postgis_full_version() :? POSTGIS="3.6.1 f533623" [EXTENSION] PGSQL="170" GEOS="3.12.1-CAPI-1.18.1" PROJ="9.4.0 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.4.0) GDAL="GDAL 3.8.4, released 2024/02/08" LIBXML="2.9.14" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" RASTER When I execute this query: SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; I get the following error: ERROR: operator is not unique: public.geometry = public.geometry It seems to be a regression, since I didn't have this error on previous versions of PostGIS (3.5). How can this problem be solved? Thanks in advance for you help, Cedric -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramsey at cleverelephant.ca Thu Jan 8 08:25:48 2026 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Thu, 8 Jan 2026 08:25:48 -0800 Subject: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry In-Reply-To: <32e1df4b-dfbd-4a95-9271-98b3cd06cebe@ign.fr> References: <32e1df4b-dfbd-4a95-9271-98b3cd06cebe@ign.fr> Message-ID: This is odd, I am not able to replicate... -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- POSTGIS="3.6.1dev 3.6.0-6-gdb18a9a49" PGSQL="180" GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.3.0 NETWORK_ENABLED=ON URL_ENDPOINT= https://cdn.proj.org USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj DATABASE_PATH=/usr/local/share/proj/proj.db" (compiled against PROJ 9.3.0) LIBXML="2.9.13" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" (1 row) postgis_reg=# SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; ?column? ---------- t (1 row) Is this a database that has gone through upgrade stages, or a blank fresh database? P On Thu, Jan 8, 2026 at 8:21?AM Cedric Duprez wrote: > Hi all, > > I'm facing a potential bug with PostGIS 3.6.1 on PostgreSQL 17.7. > Here is what I get with postgis_full_version() : POSTGIS="3.6.1 f533623" > [EXTENSION] PGSQL="170" GEOS="3.12.1-CAPI-1.18.1" PROJ="9.4.0 > 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.4.0) GDAL="GDAL 3.8.4, released 2024/02/08" > LIBXML="2.9.14" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" > RASTER > > When I execute this query: > SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; > I get the following error: > ERROR: operator is not unique: public.geometry = public.geometry > > It seems to be a regression, since I didn't have this error on previous > versions of PostGIS (3.5). > > How can this problem be solved? > Thanks in advance for you help, > > Cedric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.duprez at ign.fr Thu Jan 8 08:52:33 2026 From: cedric.duprez at ign.fr (Cedric Duprez) Date: Thu, 8 Jan 2026 17:52:33 +0100 Subject: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry In-Reply-To: References: <32e1df4b-dfbd-4a95-9271-98b3cd06cebe@ign.fr> Message-ID: Hi Paul, Thanks for your answer. The database was restored from a cold physical backup (PGDATA copy). Cedric Le 08/01/2026 ? 17:25, Paul Ramsey a ?crit?: > This is odd, I am not able to replicate... > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > ?POSTGIS="3.6.1dev 3.6.0-6-gdb18a9a49" PGSQL="180" > GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.3.0 NETWORK_ENABLED=ON > URL_ENDPOINT=https://cdn.proj.org > USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application > Support/proj DATABASE_PATH=/usr/local/share/proj/proj.db" (compiled > against PROJ 9.3.0) LIBXML="2.9.13" LIBJSON="0.17" LIBPROTOBUF="1.4.1" > WAGYU="0.5.0 (Internal)" > (1 row) > > postgis_reg=# SELECT 'POINT EMPTY'::public.geometry = 'POINT > EMPTY'::public.geometry; > ??column? > ---------- > ?t > (1 row) > > > Is this a database that has gone through upgrade stages, or a blank > fresh database? > > P > > On Thu, Jan 8, 2026 at 8:21?AM Cedric Duprez wrote: > > Hi all, > > I'm facing a potential bug with PostGIS 3.6.1 on PostgreSQL 17.7. > Here is what I get with postgis_full_version() : POSTGIS="3.6.1 > f533623" [EXTENSION] PGSQL="170" GEOS="3.12.1-CAPI-1.18.1" > PROJ="9.4.0 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.4.0) GDAL="GDAL 3.8.4, released 2024/02/08" LIBXML="2.9.14" > LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" RASTER > > When I execute this query: > SELECT 'POINT EMPTY'::public.geometry = 'POINT > EMPTY'::public.geometry; > I get the following error: > ERROR: operator is not unique: public.geometry = public.geometry > > It seems to be a regression, since I didn't have this error on > previous versions of PostGIS (3.5). > > How can this problem be solved? > Thanks in advance for you help, > > Cedric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arthurbazin at gmail.com Thu Jan 8 08:54:46 2026 From: arthurbazin at gmail.com (Arthur Bazin) Date: Thu, 8 Jan 2026 17:54:46 +0100 Subject: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry In-Reply-To: References: <32e1df4b-dfbd-4a95-9271-98b3cd06cebe@ign.fr> Message-ID: @paul, you have not the exact same version of PostGIS and therefore of GEOS and PROJ. Maybe the origin of the non reproductibility ? Best regards Arthur Le jeu. 8 janv. 2026, 17:26, Paul Ramsey via postgis-users < postgis-users at lists.osgeo.org> a ?crit : > This is odd, I am not able to replicate... > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > POSTGIS="3.6.1dev 3.6.0-6-gdb18a9a49" PGSQL="180" > GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.3.0 NETWORK_ENABLED=ON URL_ENDPOINT= > https://cdn.proj.org > USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj > DATABASE_PATH=/usr/local/share/proj/proj.db" (compiled against PROJ 9.3.0) > LIBXML="2.9.13" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" > (1 row) > > postgis_reg=# SELECT 'POINT EMPTY'::public.geometry = 'POINT > EMPTY'::public.geometry; > ?column? > ---------- > t > (1 row) > > > Is this a database that has gone through upgrade stages, or a blank fresh > database? > > P > > On Thu, Jan 8, 2026 at 8:21?AM Cedric Duprez wrote: > >> Hi all, >> >> I'm facing a potential bug with PostGIS 3.6.1 on PostgreSQL 17.7. >> Here is what I get with postgis_full_version() : POSTGIS="3.6.1 f533623" >> [EXTENSION] PGSQL="170" GEOS="3.12.1-CAPI-1.18.1" PROJ="9.4.0 >> 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.4.0) GDAL="GDAL 3.8.4, released 2024/02/08" >> LIBXML="2.9.14" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" >> RASTER >> >> When I execute this query: >> SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; >> I get the following error: >> ERROR: operator is not unique: public.geometry = public.geometry >> >> It seems to be a regression, since I didn't have this error on previous >> versions of PostGIS (3.5). >> >> How can this problem be solved? >> Thanks in advance for you help, >> >> Cedric >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lr at pcorp.us Thu Jan 8 08:58:50 2026 From: lr at pcorp.us (Regina Obe) Date: Thu, 8 Jan 2026 11:58:50 -0500 Subject: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry In-Reply-To: References: <32e1df4b-dfbd-4a95-9271-98b3cd06cebe@ign.fr> Message-ID: <000a01dc80c0$107ee4e0$317caea0$@pcorp.us> I can?t replicate on my PostgreSQL 17.7 either even with upgrading from PostGIS 3.5.3 to 3.6.1 PostgreSQL 17.7 on x86_64-windows, compiled by msvc-19.44.35221, 64-bit POSTGIS="3.6.1 3.6.1" [EXTENSION] PGSQL="170" GEOS="3.14.1-CAPI-1.20.5" PROJ="8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj DATABASE_PATH=C:\Program Files\PostgreSQL\18\share\contrib\postgis-3.6\proj\proj.db" (compiled against PROJ 8.2.1) LIBXML="2.12.5" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)" Perhaps you are having a conflict with another extension or it?s issue with upgrade from earlier. I recall we did have to fix an issue with = Can you show what the below queries output: SELECT oprcode, oprleft::regtype, oprright::regtype FROM pg_catalog.pg_operator WHERE oprname = '=' AND oprleft::regtype::text IN('geometry', 'geography') ORDER BY oprleft, oprright; Should be: oprcode | oprleft | oprright --------------+-----------+----------- geometry_eq | geometry | geometry geography_eq | geography | geography (2 rows) SELECT extname, extversion FROM pg_catalog.pg_extension; From: Paul Ramsey via postgis-users Sent: Thursday, January 8, 2026 11:26 AM To: Cedric Duprez Cc: postgis-users at lists.osgeo.org Subject: Re: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry This is odd, I am not able to replicate... -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- POSTGIS="3.6.1dev 3.6.0-6-gdb18a9a49" PGSQL="180" GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.3.0 NETWORK_ENABLED=ON URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj DATABASE_PATH=/usr/local/share/proj/proj.db" (compiled against PROJ 9.3.0) LIBXML="2.9.13" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" (1 row) postgis_reg=# SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; ?column? ---------- t (1 row) Is this a database that has gone through upgrade stages, or a blank fresh database? P On Thu, Jan 8, 2026 at 8:21?AM Cedric Duprez > wrote: Hi all, I'm facing a potential bug with PostGIS 3.6.1 on PostgreSQL 17.7. Here is what I get with postgis_full_version() : POSTGIS="3.6.1 f533623" [EXTENSION] PGSQL="170" GEOS="3.12.1-CAPI-1.18.1" PROJ="9.4.0 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.4.0) GDAL="GDAL 3.8.4, released 2024/02/08" LIBXML="2.9.14" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" RASTER When I execute this query: SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; I get the following error: ERROR: operator is not unique: public.geometry = public.geometry It seems to be a regression, since I didn't have this error on previous versions of PostGIS (3.5). How can this problem be solved? Thanks in advance for you help, Cedric -------------- next part -------------- An HTML attachment was scrubbed... URL: From lr at pcorp.us Thu Jan 8 09:00:58 2026 From: lr at pcorp.us (Regina Obe) Date: Thu, 8 Jan 2026 12:00:58 -0500 Subject: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry In-Reply-To: References: <32e1df4b-dfbd-4a95-9271-98b3cd06cebe@ign.fr> Message-ID: <001a01dc80c0$5d68aed0$183a0c70$@pcorp.us> Arthur, Are you able to replicate? I can?t with the same version of PostGIS and PostgreSQL. From: Arthur Bazin Sent: Thursday, January 8, 2026 11:55 AM To: Paul Ramsey Cc: PostGIS Users Discussion Subject: Re: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry @paul, you have not the exact same version of PostGIS and therefore of GEOS and PROJ. Maybe the origin of the non reproductibility ? Best regards Arthur Le jeu. 8 janv. 2026, 17:26, Paul Ramsey via postgis-users > a ?crit : This is odd, I am not able to replicate... -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- POSTGIS="3.6.1dev 3.6.0-6-gdb18a9a49" PGSQL="180" GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.3.0 NETWORK_ENABLED=ON URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj DATABASE_PATH=/usr/local/share/proj/proj.db" (compiled against PROJ 9.3.0) LIBXML="2.9.13" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" (1 row) postgis_reg=# SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; ?column? ---------- t (1 row) Is this a database that has gone through upgrade stages, or a blank fresh database? P On Thu, Jan 8, 2026 at 8:21?AM Cedric Duprez > wrote: Hi all, I'm facing a potential bug with PostGIS 3.6.1 on PostgreSQL 17.7. Here is what I get with postgis_full_version() : POSTGIS="3.6.1 f533623" [EXTENSION] PGSQL="170" GEOS="3.12.1-CAPI-1.18.1" PROJ="9.4.0 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.4.0) GDAL="GDAL 3.8.4, released 2024/02/08" LIBXML="2.9.14" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" RASTER When I execute this query: SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; I get the following error: ERROR: operator is not unique: public.geometry = public.geometry It seems to be a regression, since I didn't have this error on previous versions of PostGIS (3.5). How can this problem be solved? Thanks in advance for you help, Cedric -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramsey at cleverelephant.ca Thu Jan 8 09:04:49 2026 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Thu, 8 Jan 2026 09:04:49 -0800 Subject: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry In-Reply-To: References: <32e1df4b-dfbd-4a95-9271-98b3cd06cebe@ign.fr> Message-ID: No, this is clearly a postgres/postgis thing, it doesn't hit on geos or proj code lines. I was testing with pg18, but I see now Regina has replicated on pg17 also, so that was the one thing I was working on clarifying in terms of reproduction. P On Thu, Jan 8, 2026 at 8:54?AM Arthur Bazin wrote: > @paul, you have not the exact same version of PostGIS and therefore of > GEOS and PROJ. > Maybe the origin of the non reproductibility ? > > Best regards > Arthur > > > > Le jeu. 8 janv. 2026, 17:26, Paul Ramsey via postgis-users < > postgis-users at lists.osgeo.org> a ?crit : > >> This is odd, I am not able to replicate... >> >> >> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> POSTGIS="3.6.1dev 3.6.0-6-gdb18a9a49" PGSQL="180" >> GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.3.0 NETWORK_ENABLED=ON URL_ENDPOINT= >> https://cdn.proj.org >> USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj >> DATABASE_PATH=/usr/local/share/proj/proj.db" (compiled against PROJ 9.3.0) >> LIBXML="2.9.13" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" >> (1 row) >> >> postgis_reg=# SELECT 'POINT EMPTY'::public.geometry = 'POINT >> EMPTY'::public.geometry; >> ?column? >> ---------- >> t >> (1 row) >> >> >> Is this a database that has gone through upgrade stages, or a blank fresh >> database? >> >> P >> >> On Thu, Jan 8, 2026 at 8:21?AM Cedric Duprez >> wrote: >> >>> Hi all, >>> >>> I'm facing a potential bug with PostGIS 3.6.1 on PostgreSQL 17.7. >>> Here is what I get with postgis_full_version() : POSTGIS="3.6.1 >>> f533623" [EXTENSION] PGSQL="170" GEOS="3.12.1-CAPI-1.18.1" PROJ="9.4.0 >>> 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.4.0) GDAL="GDAL 3.8.4, released 2024/02/08" >>> LIBXML="2.9.14" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" >>> RASTER >>> >>> When I execute this query: >>> SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; >>> I get the following error: >>> ERROR: operator is not unique: public.geometry = public.geometry >>> >>> It seems to be a regression, since I didn't have this error on previous >>> versions of PostGIS (3.5). >>> >>> How can this problem be solved? >>> Thanks in advance for you help, >>> >>> Cedric >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.duprez at ign.fr Thu Jan 8 09:05:09 2026 From: cedric.duprez at ign.fr (Cedric Duprez) Date: Thu, 8 Jan 2026 18:05:09 +0100 Subject: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry In-Reply-To: <000a01dc80c0$107ee4e0$317caea0$@pcorp.us> References: <32e1df4b-dfbd-4a95-9271-98b3cd06cebe@ign.fr> <000a01dc80c0$107ee4e0$317caea0$@pcorp.us> Message-ID: I get two lines with the following query: SELECT oprcode, oprleft::regtype, oprright::regtype FROM pg_catalog.pg_operator WHERE oprname = '=' AND oprleft::regtype::text IN('public.geometry', 'public.geography') ORDER BY oprleft, oprright; Query result: oprcode? ? ? ? ? ? |oprleft? ? ? ? ?|oprright -------------------+----------------+---------------- public.geometry_eq |public.geometry |public.geometry public.geography_eq|public.geography|public.geography Extensions are : extname? ? ? ? ? ?|extversion ------------------+---------- plpgsql? ? ? ? ? ?|1.0 ogr_fdw? ? ? ? ? ?|1.1 plr? ? ? ? ? ? ? ?|8.4.8.2 pg_stat_statements|1.11 pgcrypto? ? ? ? ? |1.3 tablefunc? ? ? ? ?|1.0 postgis_raster? ? |3.6.1 postgis? ? ? ? ? ?|3.6.1 Le 08/01/2026 ? 17:58, Regina Obe a ?crit?: > > I can?t replicate on my PostgreSQL 17.7 either even with upgrading > from PostGIS 3.5.3 to 3.6.1 > > PostgreSQL 17.7 on x86_64-windows, compiled by msvc-19.44.35221, > 64-bit POSTGIS="3.6.1 3.6.1" [EXTENSION] PGSQL="170" > GEOS="3.14.1-CAPI-1.20.5" PROJ="8.2.1 NETWORK_ENABLED=OFF > URL_ENDPOINT=https://cdn.proj.org > USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj > DATABASE_PATH=C:\Program > Files\PostgreSQL\18\share\contrib\postgis-3.6\proj\proj.db" (compiled > against PROJ 8.2.1) LIBXML="2.12.5" LIBJSON="0.12" LIBPROTOBUF="1.2.1" > WAGYU="0.5.0 (Internal)" > > Perhaps you are having a conflict with another extension or it?s issue > with upgrade from earlier.? I recall we did have to fix an issue with = > > Can you show what the below queries output: > > SELECT oprcode, oprleft::regtype, oprright::regtype > > FROM pg_catalog.pg_operator > > WHERE oprname = '=' AND oprleft::regtype::text IN('geometry', 'geography') > > ORDER BY oprleft, oprright; > > Should be: > > ?? oprcode??? |? oprleft? | oprright > > --------------+-----------+----------- > > geometry_eq? | geometry? | geometry > > geography_eq | geography | geography > > (2 rows) > > SELECT? extname, extversion FROM pg_catalog.pg_extension; > > *From:*Paul Ramsey via postgis-users > *Sent:* Thursday, January 8, 2026 11:26 AM > *To:* Cedric Duprez > *Cc:* postgis-users at lists.osgeo.org > *Subject:* Re: PostGIS 3.6.1 - ERROR: operator is not unique: > public.geometry = public.geometry > > This is odd, I am not able to replicate... > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > ?POSTGIS="3.6.1dev 3.6.0-6-gdb18a9a49" PGSQL="180" > GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.3.0 NETWORK_ENABLED=ON > URL_ENDPOINT=https://cdn.proj.org > USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application > Support/proj DATABASE_PATH=/usr/local/share/proj/proj.db" (compiled > against PROJ 9.3.0) LIBXML="2.9.13" LIBJSON="0.17" LIBPROTOBUF="1.4.1" > WAGYU="0.5.0 (Internal)" > (1 row) > > postgis_reg=# SELECT 'POINT EMPTY'::public.geometry = 'POINT > EMPTY'::public.geometry; > ??column? > ---------- > ?t > (1 row) > > Is this a database that has gone through upgrade stages, or a blank > fresh database? > > P > > On Thu, Jan 8, 2026 at 8:21?AM Cedric Duprez wrote: > > Hi all, > > I'm facing a potential bug with PostGIS 3.6.1 on PostgreSQL 17.7. > Here is what I get with postgis_full_version() : POSTGIS="3.6.1 > f533623" [EXTENSION] PGSQL="170" GEOS="3.12.1-CAPI-1.18.1" > PROJ="9.4.0 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.4.0) GDAL="GDAL 3.8.4, released 2024/02/08" LIBXML="2.9.14" > LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" RASTER > > When I execute this query: > SELECT 'POINT EMPTY'::public.geometry = 'POINT > EMPTY'::public.geometry; > I get the following error: > ERROR: operator is not unique: public.geometry = public.geometry > > It seems to be a regression, since I didn't have this error on > previous versions of PostGIS (3.5). > > How can this problem be solved? > Thanks in advance for you help, > > Cedric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arthurbazin at gmail.com Thu Jan 8 09:06:45 2026 From: arthurbazin at gmail.com (Arthur Bazin) Date: Thu, 8 Jan 2026 18:06:45 +0100 Subject: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry In-Reply-To: <001a01dc80c0$5d68aed0$183a0c70$@pcorp.us> References: <32e1df4b-dfbd-4a95-9271-98b3cd06cebe@ign.fr> <001a01dc80c0$5d68aed0$183a0c70$@pcorp.us> Message-ID: Havn't tried for now but will do it tomorrow if not resolve at this time :-) It was Just a suggestion. Keep you informed Le jeu. 8 janv. 2026, 18:01, Regina Obe a ?crit : > Arthur, > > > > Are you able to replicate? I can?t with the same version of PostGIS and > PostgreSQL. > > > > *From:* Arthur Bazin > *Sent:* Thursday, January 8, 2026 11:55 AM > *To:* Paul Ramsey > *Cc:* PostGIS Users Discussion > *Subject:* Re: PostGIS 3.6.1 - ERROR: operator is not unique: > public.geometry = public.geometry > > > > @paul, you have not the exact same version of PostGIS and therefore of > GEOS and PROJ. > > Maybe the origin of the non reproductibility ? > > > > Best regards > > Arthur > > > > > > > > Le jeu. 8 janv. 2026, 17:26, Paul Ramsey via postgis-users < > postgis-users at lists.osgeo.org> a ?crit : > > This is odd, I am not able to replicate... > > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > POSTGIS="3.6.1dev 3.6.0-6-gdb18a9a49" PGSQL="180" > GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.3.0 NETWORK_ENABLED=ON URL_ENDPOINT= > https://cdn.proj.org > USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj > DATABASE_PATH=/usr/local/share/proj/proj.db" (compiled against PROJ 9.3.0) > LIBXML="2.9.13" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" > (1 row) > > postgis_reg=# SELECT 'POINT EMPTY'::public.geometry = 'POINT > EMPTY'::public.geometry; > ?column? > ---------- > t > (1 row) > > > > > > Is this a database that has gone through upgrade stages, or a blank fresh > database? > > > > P > > > > On Thu, Jan 8, 2026 at 8:21?AM Cedric Duprez wrote: > > Hi all, > > I'm facing a potential bug with PostGIS 3.6.1 on PostgreSQL 17.7. > Here is what I get with postgis_full_version() : POSTGIS="3.6.1 f533623" > [EXTENSION] PGSQL="170" GEOS="3.12.1-CAPI-1.18.1" PROJ="9.4.0 > 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.4.0) GDAL="GDAL 3.8.4, released 2024/02/08" > LIBXML="2.9.14" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" > RASTER > > When I execute this query: > SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; > I get the following error: > ERROR: operator is not unique: public.geometry = public.geometry > > It seems to be a regression, since I didn't have this error on previous > versions of PostGIS (3.5). > > How can this problem be solved? > Thanks in advance for you help, > > Cedric > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lr at pcorp.us Thu Jan 8 09:14:58 2026 From: lr at pcorp.us (Regina Obe) Date: Thu, 8 Jan 2026 12:14:58 -0500 Subject: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry In-Reply-To: References: <32e1df4b-dfbd-4a95-9271-98b3cd06cebe@ign.fr> <000a01dc80c0$107ee4e0$317caea0$@pcorp.us> Message-ID: <003101dc80c2$51956bf0$f4c043d0$@pcorp.us> Cedric, Good news. I was able to replicate. I noticed in your output you have the fully qualified type name, which means you don?t have postgis schema in your search path. To replicate I did: set search_path='pg_catalog'; SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; Gives: ERROR: operator is not unique: public.geometry = public.geometry LINE 1: SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::publi... ^ So I?m guessing we have some code in our = path that is not schema qualified. I?ve ticketed the issue here: https://trac.osgeo.org/postgis/ticket/6033 Paul, Can you confirm you can replicate by changing your search_path? From: Cedric Duprez Sent: Thursday, January 8, 2026 12:05 PM To: Regina Obe ; 'Paul Ramsey' Cc: postgis-users at lists.osgeo.org Subject: Re: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry I get two lines with the following query: SELECT oprcode, oprleft::regtype, oprright::regtype FROM pg_catalog.pg_operator WHERE oprname = '=' AND oprleft::regtype::text IN('public.geometry', 'public.geography') ORDER BY oprleft, oprright; Query result: oprcode |oprleft |oprright -------------------+----------------+---------------- public.geometry_eq |public.geometry |public.geometry public.geography_eq|public.geography|public.geography Extensions are : extname |extversion ------------------+---------- plpgsql |1.0 ogr_fdw |1.1 plr |8.4.8.2 pg_stat_statements|1.11 pgcrypto |1.3 tablefunc |1.0 postgis_raster |3.6.1 postgis |3.6.1 Le 08/01/2026 ? 17:58, Regina Obe a ?crit : I can?t replicate on my PostgreSQL 17.7 either even with upgrading from PostGIS 3.5.3 to 3.6.1 PostgreSQL 17.7 on x86_64-windows, compiled by msvc-19.44.35221, 64-bit POSTGIS="3.6.1 3.6.1" [EXTENSION] PGSQL="170" GEOS="3.14.1-CAPI-1.20.5" PROJ="8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj DATABASE_PATH=C:\Program Files\PostgreSQL\18\share\contrib\postgis-3.6\proj\proj.db" (compiled against PROJ 8.2.1) LIBXML="2.12.5" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)" Perhaps you are having a conflict with another extension or it?s issue with upgrade from earlier. I recall we did have to fix an issue with = Can you show what the below queries output: SELECT oprcode, oprleft::regtype, oprright::regtype FROM pg_catalog.pg_operator WHERE oprname = '=' AND oprleft::regtype::text IN('geometry', 'geography') ORDER BY oprleft, oprright; Should be: oprcode | oprleft | oprright --------------+-----------+----------- geometry_eq | geometry | geometry geography_eq | geography | geography (2 rows) SELECT extname, extversion FROM pg_catalog.pg_extension; From: Paul Ramsey via postgis-users Sent: Thursday, January 8, 2026 11:26 AM To: Cedric Duprez Cc: postgis-users at lists.osgeo.org Subject: Re: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry This is odd, I am not able to replicate... -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- POSTGIS="3.6.1dev 3.6.0-6-gdb18a9a49" PGSQL="180" GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.3.0 NETWORK_ENABLED=ON URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj DATABASE_PATH=/usr/local/share/proj/proj.db" (compiled against PROJ 9.3.0) LIBXML="2.9.13" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" (1 row) postgis_reg=# SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; ?column? ---------- t (1 row) Is this a database that has gone through upgrade stages, or a blank fresh database? P On Thu, Jan 8, 2026 at 8:21?AM Cedric Duprez > wrote: Hi all, I'm facing a potential bug with PostGIS 3.6.1 on PostgreSQL 17.7. Here is what I get with postgis_full_version() : POSTGIS="3.6.1 f533623" [EXTENSION] PGSQL="170" GEOS="3.12.1-CAPI-1.18.1" PROJ="9.4.0 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.4.0) GDAL="GDAL 3.8.4, released 2024/02/08" LIBXML="2.9.14" LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" RASTER When I execute this query: SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; I get the following error: ERROR: operator is not unique: public.geometry = public.geometry It seems to be a regression, since I didn't have this error on previous versions of PostGIS (3.5). How can this problem be solved? Thanks in advance for you help, Cedric -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.duprez at ign.fr Thu Jan 8 09:30:24 2026 From: cedric.duprez at ign.fr (Cedric Duprez) Date: Thu, 8 Jan 2026 18:30:24 +0100 Subject: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry In-Reply-To: <003101dc80c2$51956bf0$f4c043d0$@pcorp.us> References: <32e1df4b-dfbd-4a95-9271-98b3cd06cebe@ign.fr> <000a01dc80c0$107ee4e0$317caea0$@pcorp.us> <003101dc80c2$51956bf0$f4c043d0$@pcorp.us> Message-ID: <387b91ce-92e0-4d5c-aa29-9c0c392981b8@ign.fr> Well done! You're right, I changed my search path excluding "public" from it before playing the query. If I add "public" in the search path, it works fine again. Cedric Le 08/01/2026 ? 18:14, Regina Obe a ?crit?: > > Cedric, > > Good news.? I was able to replicate. > > I noticed in your output you have the fully qualified type name, which > means you don?t have postgis schema in your search path. > > To replicate I did: > > set search_path='pg_catalog'; > > SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; > > Gives: > > ERROR: operator is not unique: public.geometry = public.geometry LINE > 1: SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::publi... ^ > > So I?m guessing we have some code in our = path that is not schema > qualified. > > I?ve ticketed the issue here: > > https://trac.osgeo.org/postgis/ticket/6033 > > Paul, > > Can you confirm you can replicate by changing your search_path? > > *From:*Cedric Duprez > *Sent:* Thursday, January 8, 2026 12:05 PM > *To:* Regina Obe ; 'Paul Ramsey' > *Cc:* postgis-users at lists.osgeo.org > *Subject:* Re: PostGIS 3.6.1 - ERROR: operator is not unique: > public.geometry = public.geometry > > I get two lines with the following query: > > SELECT oprcode, oprleft::regtype, oprright::regtype > FROM pg_catalog.pg_operator > WHERE oprname = '=' AND oprleft::regtype::text IN('public.geometry', > 'public.geography') > ORDER BY oprleft, oprright; > > Query result: > > oprcode? ? ? ? ? ? |oprleft? ? ? ? ?|oprright > -------------------+----------------+---------------- > public.geometry_eq |public.geometry |public.geometry > public.geography_eq|public.geography|public.geography > > Extensions are : > > extname? ? ? ? ? ?|extversion > ------------------+---------- > plpgsql? ? ? ? ? ?|1.0 > ogr_fdw? ? ? ? ? ?|1.1 > plr? ? ? ? ? ? ? ?|8.4.8.2 > pg_stat_statements|1.11 > pgcrypto? ? ? ? ? |1.3 > tablefunc? ? ? ? ?|1.0 > postgis_raster? ? |3.6.1 > postgis? ? ? ? ? ?|3.6.1 > > Le 08/01/2026 ? 17:58, Regina Obe a ?crit?: > > I can?t replicate on my PostgreSQL 17.7 either even with upgrading > from PostGIS 3.5.3 to 3.6.1 > > PostgreSQL 17.7 on x86_64-windows, compiled by msvc-19.44.35221, > 64-bit POSTGIS="3.6.1 3.6.1" [EXTENSION] PGSQL="170" > GEOS="3.14.1-CAPI-1.20.5" PROJ="8.2.1 NETWORK_ENABLED=OFF > URL_ENDPOINT=https://cdn.proj.org > USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj > > DATABASE_PATH=C:\Program > Files\PostgreSQL\18\share\contrib\postgis-3.6\proj\proj.db" > (compiled against PROJ 8.2.1) LIBXML="2.12.5" LIBJSON="0.12" > LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)" > > Perhaps you are having a conflict with another extension or it?s > issue with upgrade from earlier.? I recall we did have to fix an > issue with = > > Can you show what the below queries output: > > SELECT oprcode, oprleft::regtype, oprright::regtype > > FROM pg_catalog.pg_operator > > WHERE oprname = '=' AND oprleft::regtype::text IN('geometry', > 'geography') > > ORDER BY oprleft, oprright; > > Should be: > > ?? oprcode??? |? oprleft? | oprright > > --------------+-----------+----------- > > geometry_eq? | geometry? | geometry > > geography_eq | geography | geography > > (2 rows) > > SELECT? extname, extversion FROM pg_catalog.pg_extension; > > *From:*Paul Ramsey via postgis-users > > > *Sent:* Thursday, January 8, 2026 11:26 AM > *To:* Cedric Duprez > > *Cc:* postgis-users at lists.osgeo.org > *Subject:* Re: PostGIS 3.6.1 - ERROR: operator is not unique: > public.geometry = public.geometry > > This is odd, I am not able to replicate... > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > ?POSTGIS="3.6.1dev 3.6.0-6-gdb18a9a49" PGSQL="180" > GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.3.0 NETWORK_ENABLED=ON > URL_ENDPOINT=https://cdn.proj.org > USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application > Support/proj DATABASE_PATH=/usr/local/share/proj/proj.db" > (compiled against PROJ 9.3.0) LIBXML="2.9.13" LIBJSON="0.17" > LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" > (1 row) > > postgis_reg=# SELECT 'POINT EMPTY'::public.geometry = 'POINT > EMPTY'::public.geometry; > ??column? > ---------- > ?t > (1 row) > > Is this a database that has gone through upgrade stages, or a > blank fresh database? > > P > > On Thu, Jan 8, 2026 at 8:21?AM Cedric Duprez > wrote: > > Hi all, > > I'm facing a potential bug with PostGIS 3.6.1 on PostgreSQL 17.7. > Here is what I get with postgis_full_version() : > POSTGIS="3.6.1 f533623" [EXTENSION] PGSQL="170" > GEOS="3.12.1-CAPI-1.18.1" PROJ="9.4.0 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.4.0) GDAL="GDAL 3.8.4, released 2024/02/08" LIBXML="2.9.14" > LIBJSON="0.17" LIBPROTOBUF="1.4.1" WAGYU="0.5.0 (Internal)" RASTER > > When I execute this query: > SELECT 'POINT EMPTY'::public.geometry = 'POINT > EMPTY'::public.geometry; > I get the following error: > ERROR: operator is not unique: public.geometry = public.geometry > > It seems to be a regression, since I didn't have this error on > previous versions of PostGIS (3.5). > > How can this problem be solved? > Thanks in advance for you help, > > Cedric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramsey at cleverelephant.ca Thu Jan 8 09:36:44 2026 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Thu, 8 Jan 2026 09:36:44 -0800 Subject: PostGIS 3.6.1 - ERROR: operator is not unique: public.geometry = public.geometry In-Reply-To: <003101dc80c2$51956bf0$f4c043d0$@pcorp.us> References: <32e1df4b-dfbd-4a95-9271-98b3cd06cebe@ign.fr> <000a01dc80c0$107ee4e0$317caea0$@pcorp.us> <003101dc80c2$51956bf0$f4c043d0$@pcorp.us> Message-ID: On Thu, Jan 8, 2026 at 9:15?AM Regina Obe wrote: > Cedric, > > > > Good news. I was able to replicate. > > > > I noticed in your output you have the fully qualified type name, which > means you don?t have postgis schema in your search path. > > > > To replicate I did: > > > > set search_path='pg_catalog'; > > SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::public.geometry; > > > > > > Gives: > > > > ERROR: operator is not unique: public.geometry = public.geometry LINE 1: > SELECT 'POINT EMPTY'::public.geometry = 'POINT EMPTY'::publi... ^ > > > > > > So I?m guessing we have some code in our = path that is not schema > qualified. > > > > I?ve ticketed the issue here: > > > > https://trac.osgeo.org/postgis/ticket/6033 > > > > Paul, > > Can you confirm you can replicate by changing your search_path? > > > Yes, that replicates on my pg18 also. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ari.jolma at gmail.com Tue Jan 13 22:12:05 2026 From: ari.jolma at gmail.com (Ari Jolma) Date: Wed, 14 Jan 2026 08:12:05 +0200 Subject: postgis_extensions_upgrade() issue with pg_init_privs Message-ID: <6ff366de-8e33-4ad6-8cb9-469e273d7f52@gmail.com> Hi all, https://www.postgresql.org/message-id/flat/1573808483712.96817 at Optiver.com is about pg_dump problems after dropped roles, which may cause?postgresql major version update failing. I witnessed this on our PostgreSQL AWS RDS installation (version 15.12, upgrading to 17.4) and I had to ask AWS Support to fix the issue - I could not do it since RDS users do not have full access to the cluster. I was wondering what caused it since it was not in all our databases with PostGIS extension installed. Playing around revealed a possible route to the situation where the major version upgrade fails and needs fixing by the support. I have PostGIS extension in a database (apparently it is 3.3.3 although? SELECT postgis_full_version(); shows 3.5.1) and it has probably not been upgraded. Issuing select objoid, initprivs from pg_init_privs where privtype='e'; shows {rdsadmin=arwdDxtm/rdsadmin,=r/rdsadmin} and objoids point to postgis installed views and table. When I now issue select postgis_extensions_upgrade(); and it says Updating extension postgis 3.3.3 Upgrade to version 3.5.1 completed And now the above query on pg_init_privs shows long lists on initprivs with all users on it. My guess is that if I now drop any of those users, the result is that the cluster may become not upgradeable. This may be only related to pre-17 PostgreSQL as the drop user behavior was fixed somehow regarding?pg_init_privs: https://www.postgresql.org/message-id/1484313.1764115685%40sss.pgh.pa.us This may be just an inconvenience for self-managed PostgreSQL installations but it's a main PITA for AWS RDS which is a "managed service". Best regards, Ari -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtreglia at gmail.com Thu Jan 15 09:46:03 2026 From: mtreglia at gmail.com (Mike Treglia) Date: Thu, 15 Jan 2026 12:46:03 -0500 Subject: Best ways around memory Error on large st_union for overlay processing Message-ID: Hi all, I'm working on combining a bunch of different data layers into an ultimately flattened set of polygons within one layer, with attributes for the various input layers as individual columns in the output layer. I'm following the general approach described in this blog post - https://blog.cleverelephant.ca/2019/07/postgis-overlays.html The datasets I'm dealing with are large and complex, so I'm using st_dumprings to get the exterior and interior parts of polygons delineated, and then extracting and unioning all of the exterior rings, when I get a memory error. In other words, when I run the following, I get the the subsequent error CREATE TABLE boundaries AS SELECT ST_Union(ST_ExteriorRing(geom)) AS geom FROM circles; SQL Error [53200]: ERROR: out of memory Detail: Failed on request of size 70544. Where: parallel worker I'm trying an approach of splitting up the polygons based on a grid, such that I can run the above and group by a grid cell ID value... need to try adjusting that as I just got a memory error there as well, but before I go further just figured I'd check: Is there an obvious or more optimal way to do that st_union(st_exteriorring(geom)) step for large datasets? I'm running this in AWS Aurora Serverless, with the following specs in case that helps. Thanks so much for any advice. Best regards, Mike POSTGIS="3.5.1 0" [EXTENSION] PGSQL="140" GEOS="3.13.0-CAPI-1.19.0" PROJ="9.5.0 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/tmp/proj DATABASE_PATH=/rdsdbbin/aurora-14.17.14.17.4.28991.0/bin/../share/postgresql/proj/proj.db" GDAL="GDAL 3.9.3, released 2024/10/07" LIBXML="2.12.5" LIBJSON="0.15.99" LIBPROTOBUF="1.3.0" WAGYU="0.5.0 (Internal)" (core procs from "3.3.3 0" need upgrade) TOPOLOGY (topology procs from "3.3.3 0" need upgrade) RASTER (raster procs from "3.3.3 0" need upgrade) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramsey at cleverelephant.ca Thu Jan 15 10:16:47 2026 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Thu, 15 Jan 2026 10:16:47 -0800 Subject: Best ways around memory Error on large st_union for overlay processing In-Reply-To: References: Message-ID: <0AE26A7D-3C4C-4010-9485-7FB30E859315@cleverelephant.ca> > On Jan 15, 2026, at 9:46?AM, Mike Treglia wrote: > > Is there an obvious or more optimal way to do that st_union(st_exteriorring(geom)) step for large datasets? > Just spitballing? Starting with an ST_Subdivide on all the rings, writing out the ring segments and a unique key into a staging table. Then do the st_union on a gridded basis. I think that should be safe? The part I worry about is doing the polygon building, unless you do the build with overlapping grid cells to select potential input ring segments, and then post-filter the polygon collection you get to remove any overlapping/duplicated polygons. My concern is that a very large input polygon relative to the grid size might fail to be built, if all its component pieces do not happen to fall into a single grid cell. At some point you end up building something of the scale and complexity of the topology module, and maybe you would be able to get some good results starting there instead. P. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtreglia at gmail.com Thu Jan 15 17:59:43 2026 From: mtreglia at gmail.com (Mike Treglia) Date: Thu, 15 Jan 2026 20:59:43 -0500 Subject: Best ways around memory Error on large st_union for overlay processing In-Reply-To: <0AE26A7D-3C4C-4010-9485-7FB30E859315@cleverelephant.ca> References: <0AE26A7D-3C4C-4010-9485-7FB30E859315@cleverelephant.ca> Message-ID: Thanks, Paul! Appreciate these thoughts - and considerations. I'll keep these ideas in mind as I proceed and see where I end up. Definitely trying to keep things simpler than not all things considered... we'll see! Best, Mike On Thu, Jan 15, 2026 at 1:16?PM Paul Ramsey wrote: > > > On Jan 15, 2026, at 9:46?AM, Mike Treglia wrote: > > Is there an obvious or more optimal way to do that > st_union(st_exteriorring(geom)) step for large datasets? > > > Just spitballing? > > Starting with an ST_Subdivide on all the rings, writing out the ring > segments and a unique key into a staging table. > Then do the st_union on a gridded basis. I think that should be safe? > The part I worry about is doing the polygon building, unless you do the > build with overlapping grid cells to select potential input ring segments, > and then post-filter the polygon collection you get to remove any > overlapping/duplicated polygons. My concern is that a very large input > polygon relative to the grid size might fail to be built, if all its > component pieces do not happen to fall into a single grid cell. > At some point you end up building something of the scale and complexity of > the topology module, and maybe you would be able to get some good results > starting there instead. > P. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramsey at cleverelephant.ca Fri Jan 16 09:29:16 2026 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Fri, 16 Jan 2026 09:29:16 -0800 Subject: Best ways around memory Error on large st_union for overlay processing In-Reply-To: References: <0AE26A7D-3C4C-4010-9485-7FB30E859315@cleverelephant.ca> Message-ID: It's hard! I was just thinking that a light snap using the ST_ReducePrecision might also be good to avoid the generation of some super-tiny slivers, but whether that's done during preprocessing of rings or using ST_CoverageSimplify after polygons are re-formed is an unknown. I look forward to your blog post! P On Thu, Jan 15, 2026 at 5:59?PM Mike Treglia wrote: > Thanks, Paul! Appreciate these thoughts - and considerations. I'll keep > these ideas in mind as I proceed and see where I end up. Definitely trying > to keep things simpler than not all things considered... we'll see! > Best, > Mike > > On Thu, Jan 15, 2026 at 1:16?PM Paul Ramsey > wrote: > >> >> >> On Jan 15, 2026, at 9:46?AM, Mike Treglia wrote: >> >> Is there an obvious or more optimal way to do that >> st_union(st_exteriorring(geom)) step for large datasets? >> >> >> Just spitballing? >> >> Starting with an ST_Subdivide on all the rings, writing out the ring >> segments and a unique key into a staging table. >> Then do the st_union on a gridded basis. I think that should be safe? >> The part I worry about is doing the polygon building, unless you do the >> build with overlapping grid cells to select potential input ring segments, >> and then post-filter the polygon collection you get to remove any >> overlapping/duplicated polygons. My concern is that a very large input >> polygon relative to the grid size might fail to be built, if all its >> component pieces do not happen to fall into a single grid cell. >> At some point you end up building something of the scale and complexity >> of the topology module, and maybe you would be able to get some good >> results starting there instead. >> P. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tadikondabharath at gmail.com Wed Jan 21 10:36:02 2026 From: tadikondabharath at gmail.com (Bharath Tadikonda) Date: Wed, 21 Jan 2026 13:36:02 -0500 Subject: =?UTF-8?Q?Inquiry_on_planned_PostGIS_releases_and_minor=2Dversio?= =?UTF-8?Q?n_behavior_=28now=E2=80=93Feb_28=29?= Message-ID: Hello PostGIS Team, I?m a PostgreSQL Database Engineer managing production PostgreSQL/PostGIS workloads on AWS RDS/Aurora. We are planning a PostgreSQL *minor upgrade* (PostgreSQL 16.6 ? 16.11) in the near term. In our environment, past *PostGIS minor/patch releases* have occasionally caused operational issues due to changes in function behavior, even when PostgreSQL itself was a minor upgrade. Because AWS may bundle a newer PostGIS minor version along with a PostgreSQL minor upgrade, we want to plan and execute testing and production rollout as close together as possible. To help us plan safely, I wanted to ask: 1. *Are there any planned PostGIS releases (minor or patch) between now and February 28?* - If yes, which versions are anticipated? - If not, when is the next postgis version release anticipated? 2. *For PostGIS minor/patch releases (e.g., 3.6.x ? 3.6.y):* - Are changes strictly bug fixes, or can they include behavioral changes to existing functions? - Are there specific classes of functions (geometry processing, topology, raster, etc.) where behavior changes are more likely? 3. *Release notes & compatibility guidance:* - Is there a recommended way to identify *function-level behavior changes* between minor versions (beyond high-level release notes)? - Are there guarantees or best-practice guidance around backward compatibility expectations for PostGIS patch releases? 4. *Operational best practices:* - Do you recommend pinning PostGIS patch versions in production where possible, or validating only specific functions we rely on most during upgrades? Any guidance you can share will help us reduce risk and plan upgrades more confidently. Thank you for your time and for all the work you do on PostGIS. Best regards, Bharath PostgreSQL Database Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Wed Jan 21 10:43:36 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 21 Jan 2026 13:43:36 -0500 Subject: Inquiry on planned PostGIS releases and minor-version behavior =?utf-8?Q?=28now=E2=80=93Feb?= 28) In-Reply-To: (Bharath Tadikonda's message of "Wed, 21 Jan 2026 13:36:02 -0500") References: Message-ID: I'm not anybody in particular on this list, but my opinion is that when companies use Free Software and ask for $0 help on lists, they should write from a company list and identify the company, rather than some gmail address. If I were somebody important, I might make that a rule :-) Overall, it looks like you need a consultant, or to hire a test engineer and actually run things on your staging servers. If you do that, or if you just upgrade, please report back to the list how things went so this can be mutual assistance. Can you confirm that you have permission to send an on-list message talking about how things went? From pramsey at cleverelephant.ca Wed Jan 21 11:05:46 2026 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Wed, 21 Jan 2026 11:05:46 -0800 Subject: =?UTF-8?Q?Re=3A_Inquiry_on_planned_PostGIS_releases_and_minor=2Dve?= =?UTF-8?Q?rsion_behavior_=28now=E2=80=93Feb_28=29?= In-Reply-To: References: Message-ID: On Wed, Jan 21, 2026 at 10:36?AM Bharath Tadikonda < tadikondabharath at gmail.com> wrote: > Are there any planned PostGIS releases (minor or patch) between now and February 28? No, but that doesn't mean they won't happen. Minor releases expect in the fall / late summer. Patch releases expect any time we feel the urge, either when enough fixes have piled up, or a particularly nasty bug has been repaired. > If not, when is the next postgis version release anticipated? Cannot say, except for what is stated above. > For PostGIS minor/patch releases (e.g., 3.6.x ? 3.6.y): > Are changes strictly bug fixes, or can they include behavioral changes to existing functions? No deliberate behaviour change, except if existing behaviour is wrong. At any time, if your provider updates the GEOS or Proj library at more than a patch level, that could cause behaviour changes in PostGIS, so you must watch both PostGIS and the major libraries it uses. > Are there specific classes of functions (geometry processing, topology, raster, etc.) where behavior changes are more likely? Not really. > Release notes & compatibility guidance: > Is there a recommended way to identify function-level behavior changes between minor versions (beyond high-level release notes)? Nope. > Are there guarantees or best-practice guidance around backward compatibility expectations for PostGIS patch releases? As above, we strive to follow semver guarantees. Bug fixes only on patch. Backward compatible changes and new features only on minor. Backwards incompatibilities restricted to major. > Operational best practices: > Do you recommend pinning PostGIS patch versions in production where possible, or validating only specific functions we rely on most during upgrades? No, I recommend always having the latest patch release at all times for PostGIS, GEOS, Proj. I recommend regularly testing and pushing GEOS and PostGIS forward in minor versions as often as possible, as performance and correctness improvements are always landing. Many of the tickets that are reported to us are just people with old pinned versions, whose problems were long since fixed. Only relatively small bugs get back-ported, large improvements in behaviour and performance (like RelateNG or OverlayNG) are too big to back-port, and only available through upgrade. > Any guidance you can share will help us reduce risk and plan upgrades more confidently. I'm no ops genius. Hope the above is useful. ATB, P > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lr at pcorp.us Wed Jan 21 11:08:56 2026 From: lr at pcorp.us (Regina Obe) Date: Wed, 21 Jan 2026 14:08:56 -0500 Subject: =?utf-8?Q?RE:_Inquiry_on_planned_PostGIS_r?= =?utf-8?Q?eleases_and_minor-version_behavi?= =?utf-8?Q?or_=28now=E2=80=93Feb_28=29?= In-Reply-To: References: Message-ID: <002401dc8b09$64a454d0$2decfe70$@pcorp.us> Bharath, The best advice I can give is to look at the upcoming NEWS items https://gitea.osgeo.org/postgis/postgis/src/branch/stable-3.6/NEWS and yes we most likely will do a micro release before February 28 From: Bharath Tadikonda Sent: Wednesday, January 21, 2026 1:36 PM To: postgis-users at lists.osgeo.org Subject: Inquiry on planned PostGIS releases and minor-version behavior (now?Feb 28) Hello PostGIS Team, I?m a PostgreSQL Database Engineer managing production PostgreSQL/PostGIS workloads on AWS RDS/Aurora. We are planning a PostgreSQL minor upgrade (PostgreSQL 16.6 ? 16.11) in the near term. In our environment, past PostGIS minor/patch releases have occasionally caused operational issues due to changes in function behavior, even when PostgreSQL itself was a minor upgrade. Because AWS may bundle a newer PostGIS minor version along with a PostgreSQL minor upgrade, we want to plan and execute testing and production rollout as close together as possible. To help us plan safely, I wanted to ask: 1. Are there any planned PostGIS releases (minor or patch) between now and February 28? * If yes, which versions are anticipated? * If not, when is the next postgis version release anticipated? 2. For PostGIS minor/patch releases (e.g., 3.6.x ? 3.6.y): * Are changes strictly bug fixes, or can they include behavioral changes to existing functions? * Are there specific classes of functions (geometry processing, topology, raster, etc.) where behavior changes are more likely? 3. Release notes & compatibility guidance: * Is there a recommended way to identify function-level behavior changes between minor versions (beyond high-level release notes)? * Are there guarantees or best-practice guidance around backward compatibility expectations for PostGIS patch releases? 4. Operational best practices: * Do you recommend pinning PostGIS patch versions in production where possible, or validating only specific functions we rely on most during upgrades? Any guidance you can share will help us reduce risk and plan upgrades more confidently. Thank you for your time and for all the work you do on PostGIS. Best regards, Bharath PostgreSQL Database Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From tadikondabharath at gmail.com Wed Jan 21 11:17:31 2026 From: tadikondabharath at gmail.com (Bharath Tadikonda) Date: Wed, 21 Jan 2026 14:17:31 -0500 Subject: =?UTF-8?Q?Re=3A_Inquiry_on_planned_PostGIS_releases_and_minor=2Dve?= =?UTF-8?Q?rsion_behavior_=28now=E2=80=93Feb_28=29?= In-Reply-To: <002401dc8b09$64a454d0$2decfe70$@pcorp.us> References: <002401dc8b09$64a454d0$2decfe70$@pcorp.us> Message-ID: Thank you, Paul and Regina, for your responses. I really appreciate your time and the helpful information. I?ll review this on our side and will reach out if we need any further clarification On Wed, Jan 21, 2026 at 2:09?PM Regina Obe wrote: > Bharath, > > > > The best advice I can give is to look at the upcoming NEWS items > > > > https://gitea.osgeo.org/postgis/postgis/src/branch/stable-3.6/NEWS > > > > and yes we most likely will do a micro release before February 28 > > > > > > *From:* Bharath Tadikonda > *Sent:* Wednesday, January 21, 2026 1:36 PM > *To:* postgis-users at lists.osgeo.org > *Subject:* Inquiry on planned PostGIS releases and minor-version behavior > (now?Feb 28) > > > > Hello PostGIS Team, > > I?m a PostgreSQL Database Engineer managing production PostgreSQL/PostGIS > workloads on AWS RDS/Aurora. > > We are planning a PostgreSQL *minor upgrade* (PostgreSQL 16.6 ? 16.11) in > the near term. In our environment, past *PostGIS minor/patch releases* > have occasionally caused operational issues due to changes in function > behavior, even when PostgreSQL itself was a minor upgrade. Because AWS may > bundle a newer PostGIS minor version along with a PostgreSQL minor upgrade, > we want to plan and execute testing and production rollout as close > together as possible. > > To help us plan safely, I wanted to ask: > > 1. *Are there any planned PostGIS releases (minor or patch) between > now and February 28?* > > > - If yes, which versions are anticipated? > - If not, when is the next postgis version release anticipated? > > > 2. *For PostGIS minor/patch releases (e.g., 3.6.x ? 3.6.y):* > > > - Are changes strictly bug fixes, or can they include behavioral > changes to existing functions? > - Are there specific classes of functions (geometry processing, > topology, raster, etc.) where behavior changes are more likely? > > > 3. *Release notes & compatibility guidance:* > > > - Is there a recommended way to identify *function-level behavior > changes* between minor versions (beyond high-level release notes)? > - Are there guarantees or best-practice guidance around backward > compatibility expectations for PostGIS patch releases? > > > 4. *Operational best practices:* > > > - Do you recommend pinning PostGIS patch versions in production where > possible, or validating only specific functions we rely on most during > upgrades? > > Any guidance you can share will help us reduce risk and plan upgrades more > confidently. > > Thank you for your time and for all the work you do on PostGIS. > > Best regards, > Bharath > PostgreSQL Database Engineer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tadikondabharath at gmail.com Wed Jan 21 11:37:54 2026 From: tadikondabharath at gmail.com (Bharath Tadikonda) Date: Wed, 21 Jan 2026 14:37:54 -0500 Subject: =?UTF-8?Q?Re=3A_Inquiry_on_planned_PostGIS_releases_and_minor=2Dve?= =?UTF-8?Q?rsion_behavior_=28now=E2=80=93Feb_28=29?= In-Reply-To: <002401dc8b09$64a454d0$2decfe70$@pcorp.us> References: <002401dc8b09$64a454d0$2decfe70$@pcorp.us> Message-ID: Hi Regina, *"and yes we most likely will do a micro release before February 28" * Could you please let us know if there is a tentative date planned for this micro release? Additionally, will this release include any changes to *GEOS* or *PROJ*? On Wed, Jan 21, 2026 at 2:09?PM Regina Obe wrote: > Bharath, > > > > The best advice I can give is to look at the upcoming NEWS items > > > > https://gitea.osgeo.org/postgis/postgis/src/branch/stable-3.6/NEWS > > > > and yes we most likely will do a micro release before February 28 > > > > > > *From:* Bharath Tadikonda > *Sent:* Wednesday, January 21, 2026 1:36 PM > *To:* postgis-users at lists.osgeo.org > *Subject:* Inquiry on planned PostGIS releases and minor-version behavior > (now?Feb 28) > > > > Hello PostGIS Team, > > I?m a PostgreSQL Database Engineer managing production PostgreSQL/PostGIS > workloads on AWS RDS/Aurora. > > We are planning a PostgreSQL *minor upgrade* (PostgreSQL 16.6 ? 16.11) in > the near term. In our environment, past *PostGIS minor/patch releases* > have occasionally caused operational issues due to changes in function > behavior, even when PostgreSQL itself was a minor upgrade. Because AWS may > bundle a newer PostGIS minor version along with a PostgreSQL minor upgrade, > we want to plan and execute testing and production rollout as close > together as possible. > > To help us plan safely, I wanted to ask: > > 1. *Are there any planned PostGIS releases (minor or patch) between > now and February 28?* > > > - If yes, which versions are anticipated? > - If not, when is the next postgis version release anticipated? > > > 2. *For PostGIS minor/patch releases (e.g., 3.6.x ? 3.6.y):* > > > - Are changes strictly bug fixes, or can they include behavioral > changes to existing functions? > - Are there specific classes of functions (geometry processing, > topology, raster, etc.) where behavior changes are more likely? > > > 3. *Release notes & compatibility guidance:* > > > - Is there a recommended way to identify *function-level behavior > changes* between minor versions (beyond high-level release notes)? > - Are there guarantees or best-practice guidance around backward > compatibility expectations for PostGIS patch releases? > > > 4. *Operational best practices:* > > > - Do you recommend pinning PostGIS patch versions in production where > possible, or validating only specific functions we rely on most during > upgrades? > > Any guidance you can share will help us reduce risk and plan upgrades more > confidently. > > Thank you for your time and for all the work you do on PostGIS. > > Best regards, > Bharath > PostgreSQL Database Engineer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lr at pcorp.us Wed Jan 21 11:56:03 2026 From: lr at pcorp.us (Regina Obe) Date: Wed, 21 Jan 2026 14:56:03 -0500 Subject: =?utf-8?Q?RE:_Inquiry_on_planned_PostGIS_r?= =?utf-8?Q?eleases_and_minor-version_behavi?= =?utf-8?Q?or_=28now=E2=80=93Feb_28=29?= In-Reply-To: References: <002401dc8b09$64a454d0$2decfe70$@pcorp.us> Message-ID: <003a01dc8b0f$f9b2d7d0$ed188770$@pcorp.us> As Paul mentioned, we don?t have tentative date plans. We release when we feel there are enough bug fixes in the list to make it worthwhile or if enough time has passed. At the moment we generally don?t make a decision to release until about a week before we release. Not sure what you mean by GEOS/PROJ changes. Those are separate projects from PostGIS. PostGIS just relies on them. From: Bharath Tadikonda Sent: Wednesday, January 21, 2026 2:38 PM To: Regina Obe Cc: postgis-users at lists.osgeo.org Subject: Re: Inquiry on planned PostGIS releases and minor-version behavior (now?Feb 28) Hi Regina, "and yes we most likely will do a micro release before February 28" Could you please let us know if there is a tentative date planned for this micro release? Additionally, will this release include any changes to GEOS or PROJ? On Wed, Jan 21, 2026 at 2:09?PM Regina Obe > wrote: Bharath, The best advice I can give is to look at the upcoming NEWS items https://gitea.osgeo.org/postgis/postgis/src/branch/stable-3.6/NEWS and yes we most likely will do a micro release before February 28 From: Bharath Tadikonda > Sent: Wednesday, January 21, 2026 1:36 PM To: postgis-users at lists.osgeo.org Subject: Inquiry on planned PostGIS releases and minor-version behavior (now?Feb 28) Hello PostGIS Team, I?m a PostgreSQL Database Engineer managing production PostgreSQL/PostGIS workloads on AWS RDS/Aurora. We are planning a PostgreSQL minor upgrade (PostgreSQL 16.6 ? 16.11) in the near term. In our environment, past PostGIS minor/patch releases have occasionally caused operational issues due to changes in function behavior, even when PostgreSQL itself was a minor upgrade. Because AWS may bundle a newer PostGIS minor version along with a PostgreSQL minor upgrade, we want to plan and execute testing and production rollout as close together as possible. To help us plan safely, I wanted to ask: 1. Are there any planned PostGIS releases (minor or patch) between now and February 28? * If yes, which versions are anticipated? * If not, when is the next postgis version release anticipated? 2. For PostGIS minor/patch releases (e.g., 3.6.x ? 3.6.y): * Are changes strictly bug fixes, or can they include behavioral changes to existing functions? * Are there specific classes of functions (geometry processing, topology, raster, etc.) where behavior changes are more likely? 3. Release notes & compatibility guidance: * Is there a recommended way to identify function-level behavior changes between minor versions (beyond high-level release notes)? * Are there guarantees or best-practice guidance around backward compatibility expectations for PostGIS patch releases? 4. Operational best practices: * Do you recommend pinning PostGIS patch versions in production where possible, or validating only specific functions we rely on most during upgrades? Any guidance you can share will help us reduce risk and plan upgrades more confidently. Thank you for your time and for all the work you do on PostGIS. Best regards, Bharath PostgreSQL Database Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From tadikondabharath at gmail.com Wed Jan 21 11:57:19 2026 From: tadikondabharath at gmail.com (Bharath Tadikonda) Date: Wed, 21 Jan 2026 14:57:19 -0500 Subject: =?UTF-8?Q?Re=3A_Inquiry_on_planned_PostGIS_releases_and_minor=2Dve?= =?UTF-8?Q?rsion_behavior_=28now=E2=80=93Feb_28=29?= In-Reply-To: <003a01dc8b0f$f9b2d7d0$ed188770$@pcorp.us> References: <002401dc8b09$64a454d0$2decfe70$@pcorp.us> <003a01dc8b0f$f9b2d7d0$ed188770$@pcorp.us> Message-ID: Ok, thanks for the clarification. On Wed, Jan 21, 2026 at 2:56?PM Regina Obe wrote: > As Paul mentioned, we don?t have tentative date plans. We release when > we feel there are enough bug fixes in the list to make it worthwhile or if > enough time has passed. > > At the moment we generally don?t make a decision to release until about a > week before we release. > > > > Not sure what you mean by GEOS/PROJ changes. Those are separate projects > from PostGIS. PostGIS just relies on them. > > > > > > > > *From:* Bharath Tadikonda > *Sent:* Wednesday, January 21, 2026 2:38 PM > *To:* Regina Obe > *Cc:* postgis-users at lists.osgeo.org > *Subject:* Re: Inquiry on planned PostGIS releases and minor-version > behavior (now?Feb 28) > > > > Hi Regina, > > > > *"and yes we most likely will do a micro release before February 28" * > > > > Could you please let us know if there is a tentative date planned for this > micro release? Additionally, will this release include any changes to > *GEOS* or *PROJ*? > > > > On Wed, Jan 21, 2026 at 2:09?PM Regina Obe wrote: > > Bharath, > > > > The best advice I can give is to look at the upcoming NEWS items > > > > https://gitea.osgeo.org/postgis/postgis/src/branch/stable-3.6/NEWS > > > > and yes we most likely will do a micro release before February 28 > > > > > > *From:* Bharath Tadikonda > *Sent:* Wednesday, January 21, 2026 1:36 PM > *To:* postgis-users at lists.osgeo.org > *Subject:* Inquiry on planned PostGIS releases and minor-version behavior > (now?Feb 28) > > > > Hello PostGIS Team, > > I?m a PostgreSQL Database Engineer managing production PostgreSQL/PostGIS > workloads on AWS RDS/Aurora. > > We are planning a PostgreSQL *minor upgrade* (PostgreSQL 16.6 ? 16.11) in > the near term. In our environment, past *PostGIS minor/patch releases* > have occasionally caused operational issues due to changes in function > behavior, even when PostgreSQL itself was a minor upgrade. Because AWS may > bundle a newer PostGIS minor version along with a PostgreSQL minor upgrade, > we want to plan and execute testing and production rollout as close > together as possible. > > To help us plan safely, I wanted to ask: > > 1. *Are there any planned PostGIS releases (minor or patch) between > now and February 28?* > > > - If yes, which versions are anticipated? > - If not, when is the next postgis version release anticipated? > > > 2. *For PostGIS minor/patch releases (e.g., 3.6.x ? 3.6.y):* > > > - Are changes strictly bug fixes, or can they include behavioral > changes to existing functions? > - Are there specific classes of functions (geometry processing, > topology, raster, etc.) where behavior changes are more likely? > > > 3. *Release notes & compatibility guidance:* > > > - Is there a recommended way to identify *function-level behavior > changes* between minor versions (beyond high-level release notes)? > - Are there guarantees or best-practice guidance around backward > compatibility expectations for PostGIS patch releases? > > > 4. *Operational best practices:* > > > - Do you recommend pinning PostGIS patch versions in production where > possible, or validating only specific functions we rely on most during > upgrades? > > Any guidance you can share will help us reduce risk and plan upgrades more > confidently. > > Thank you for your time and for all the work you do on PostGIS. > > Best regards, > Bharath > PostgreSQL Database Engineer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sztegi at gmail.com Wed Jan 28 09:26:07 2026 From: sztegi at gmail.com (Sztegi) Date: Wed, 28 Jan 2026 18:26:07 +0100 Subject: St_GeoHash: boundary handling in non-point case Message-ID: Hi! I have bumped into something I find counter intuitive with St_GeoHash() - boundary checking for non-point objects seems stricter than for points in case precision is not set: select st_geohash(ST_MakeLine(st_point(0, 0), st_point(0.00002, 0.00002))); -- returns "" <- this is unexpected, I expected "s00000000" This breaks my assumption that st_geoshash(st_geomfromgeohash(hash)) will return the original geohash: select st_geohash(st_geomfromgeohash('s0')); -- returns "" <- I expected "s0" I bumped to this in Postgis 3.2.1 and it is still reproducible in 3.6.1 Meanwhile if precision is set OR the geometry is a point OR it doesn't touch geohash boundaries then I get what I expect: select st_geohash(st_point(0, 0), 8)); -- returns "s0000000" select st_geohash(st_point(0, 0)); --- returns "s0000000000000000000" select st_geohash(ST_MakeLine(st_point(0, 0), st_point(0.00002, 0.00002)), 8); -- returns "s0000000" select st_geohash(ST_MakeLine(st_point(0.00001, 0.00001), st_point(0.00002, 0.00002)), 8); -- returns "s0000000" select st_geohash(ST_MakeLine(st_point(0.00001, 0.00001), st_point(0.00002, 0.00002))); -- returns "s00000000" I plan to create a bug report about this, but wanted to check first on the mailing list if this is something intended. These edge cases are interesting to me because I am trying to create an implementation of st_geohash()/st_geomfromgeohash() for two Apache projects (Hive, Impala), and cross- checked my tests with the results in postgis. regards, Csaba