[SCM] PostGIS branch master updated. 3.6.0rc2-171-gafc7eeac4
git at osgeo.org
git at osgeo.org
Thu Oct 30 11:44:48 PDT 2025
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "PostGIS".
The branch, master has been updated
via afc7eeac415514ddf0ba5cfe63d42cca7716cf6b (commit)
from 7dc8c00b77b76f584ef5746b97a54b72a7d1caee (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit afc7eeac415514ddf0ba5cfe63d42cca7716cf6b
Author: Darafei Praliaskouski <me at komzpa.net>
Date: Thu Oct 30 22:44:10 2025 +0400
[doc] Clean up mentions of legacy Postgres versions
diff --git a/doc/administration.xml b/doc/administration.xml
index bd99d0dee..e7cf63d1b 100644
--- a/doc/administration.xml
+++ b/doc/administration.xml
@@ -13,8 +13,8 @@
below how to properly configure it.
</para>
- <para>As of PostGIS 2.1.3, out-of-db rasters and all raster drivers are disabled by default. In order to re-enable these, you need to set the following environment variables
- <varname>POSTGIS_GDAL_ENABLED_DRIVERS</varname> and <varname>POSTGIS_ENABLE_OUTDB_RASTERS</varname> in the server environment. For PostGIS 2.2, you can use the more cross-platform approach of setting the corresponding <xref linkend="PostGIS_GUC"/>.</para>
+ <para>Out-of-db rasters and all raster drivers are disabled by default. In order to re-enable these, you need to set the following environment variables
+ <varname>POSTGIS_GDAL_ENABLED_DRIVERS</varname> and <varname>POSTGIS_ENABLE_OUTDB_RASTERS</varname> in the server environment. You can also use the more cross-platform approach of setting the corresponding <xref linkend="PostGIS_GUC"/>.</para>
<para>If you want to enable offline raster:</para>
<programlisting>POSTGIS_ENABLE_OUTDB_RASTERS=1</programlisting>
@@ -27,7 +27,7 @@
<note><para>If you are on windows, do not quote the driver list</para></note>
<para>Setting environment variables varies depending on OS. For PostgreSQL installed on Ubuntu or Debian via apt-postgresql, the preferred way is to
- edit <filename>/etc/postgresql/<replaceable>10</replaceable>/<replaceable>main</replaceable>/environment</filename> where 10 refers to version of PostgreSQL and main refers to the cluster.</para>
+ edit <filename>/etc/postgresql/<replaceable>MAJOR</replaceable>/<replaceable>CLUSTER</replaceable>/environment</filename> where the placeholders refer to the PostgreSQL major version and cluster name.</para>
<para>On windows, if you are running as a service, you can set via System variables which for Windows 7 you can get to by right-clicking on Computer->Properties Advanced System Settings or in explorer navigating to <varname>Control Panel\All Control Panel Items\System</varname>.
Then clicking <emphasis>Advanced System Settings ->Advanced->Environment Variables</emphasis> and adding new system variables.</para>
@@ -42,8 +42,8 @@
<title>Spatially enable database using EXTENSION</title>
<para>
- If you are using PostgreSQL 9.1+ and have compiled and installed the extensions/postgis modules, you
- can turn a database into a spatial one using the EXTENSION mechanism.
+ If you have compiled and installed the extensions/postgis modules, you
+ can turn a database into a spatial one using the EXTENSION mechanism.
</para>
<para>
diff --git a/doc/database_tuning.xml b/doc/database_tuning.xml
index 6a3e4ff93..72f55f4f2 100644
--- a/doc/database_tuning.xml
+++ b/doc/database_tuning.xml
@@ -8,7 +8,7 @@
<para>For general details about optimizing PostgreSQL, refer to <link xlink:href="https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server">Tuning your PostgreSQL Server</link>.</para>
- <para>For PostgreSQL 9.4+ configuration can be set at the server level without touching <code>postgresql.conf</code> or <code>postgresql.auto.conf</code>
+ <para>PostgreSQL configuration can be set at the server level without touching <code>postgresql.conf</code> or <code>postgresql.auto.conf</code>
by using the <code>ALTER SYSTEM</code> command.</para>
<programlisting>ALTER SYSTEM SET work_mem = '256MB';
-- this forces non-startup configs to take effect for new connections
@@ -38,9 +38,8 @@ SHOW work_mem;</programlisting>
</listitem>
<listitem>
<para>
- This is generally used for table partitioning. The default for this is set to "partition" which is ideal for PostgreSQL 8.4 and above since
- it will force the planner to only analyze tables for constraint consideration if they are in an inherited hierarchy
- and not pay the planner penalty otherwise.
+ This is generally used for table partitioning. The default of "partition" forces the planner to only analyze tables for constraint consideration if they are in an inherited hierarchy
+ and avoids paying the planner penalty otherwise.
</para>
</listitem>
</itemizedlist>
@@ -52,7 +51,7 @@ SHOW work_mem;</programlisting>
<itemizedlist>
<listitem>
<para>
- Default: ~128MB in PostgreSQL 9.6
+ Default: ~128MB
</para>
</listitem>
<listitem>
@@ -65,8 +64,8 @@ SHOW work_mem;</programlisting>
<para>
<link xlink:href="https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES">max_worker_processes</link>
- This setting is only available for PostgreSQL 9.4+. For PostgreSQL 9.6+ this setting has additional importance in that it controls the
- max number of processes you can have for parallel queries.
+ controls the maximum number of background processes available to the server and therefore
+ also bounds how many workers can participate in parallel queries.
</para>
<itemizedlist>
@@ -146,8 +145,8 @@ SHOW work_mem;</programlisting>
<link xlink:href="https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER">max_parallel_workers_per_gather</link>
</para>
<para>
- This setting is only available for PostgreSQL 9.6+ and will only affect PostGIS 2.3+, since only PostGIS 2.3+ supports parallel queries.
- If set to higher than 0, then some queries such as those involving relation functions like <code>ST_Intersects</code> can use multiple processes and can run
+ Parallel query support in modern PostgreSQL and PostGIS uses this setting to decide how many workers
+ a plan may request. If set to higher than 0, then some queries such as those involving relation functions like <code>ST_Intersects</code> can use multiple processes and can run
more than twice as fast when doing so. If you have a lot of processors to spare, you should change the value of this to as many processors as you have.
Also make sure to bump up <code>max_worker_processes</code> to at least as high as this number.
</para>
diff --git a/doc/installation.xml b/doc/installation.xml
index de6ec932c..da80070c7 100644
--- a/doc/installation.xml
+++ b/doc/installation.xml
@@ -613,9 +613,9 @@ sh autogen.sh
<section xml:id="make_install_postgis_extensions">
<title>Building PostGIS Extensions and Deploying them</title>
- <para>
- The PostGIS extensions are built and installed automatically if you are using PostgreSQL 9.1+.
- </para>
+ <para>
+ The PostGIS extensions are built and installed automatically when PostgreSQL extension support is available.
+ </para>
<para>If you are building from source repository, you need to build the function descriptions first. These get built if you have docbook installed. You can also manually build with the statement:
</para>
<para>
diff --git a/doc/reference_constructor.xml b/doc/reference_constructor.xml
index 324424a7b..93d2a06cc 100644
--- a/doc/reference_constructor.xml
+++ b/doc/reference_constructor.xml
@@ -343,7 +343,7 @@ SELECT gps.track_id, ST_MakeLine(gps.geom ORDER BY gps_time) As geom
FROM gps_points As gps
GROUP BY track_id;</programlisting>
-<para>Prior to PostgreSQL 9, ordering in a subquery can be used.
+<para>When ordering within the aggregate is not possible, ordering in a subquery can be used.
However, sometimes the query plan may not respect the order of the subquery.</para>
<programlisting>
SELECT gps.track_id, ST_MakeLine(gps.geom) As geom
diff --git a/doc/reference_management.xml b/doc/reference_management.xml
index 7c46c2ac7..021cebbd7 100644
--- a/doc/reference_management.xml
+++ b/doc/reference_management.xml
@@ -267,8 +267,8 @@ SELECT f_geometry_column As col_name, type, srid, coord_dimension As ndims
------------------------------------------------------
my_schema.my_spatial_table.geom effectively removed.
--- In PostGIS 2.0+ the above is also equivalent to the standard
--- the standard alter table. Both will deregister from geometry_columns
+-- The above is also equivalent to the standard
+-- ALTER TABLE command. Both will deregister from geometry_columns
ALTER TABLE my_schema.my_spatial_table DROP column geom;
</programlisting>
</refsection>
diff --git a/doc/reference_operator.xml b/doc/reference_operator.xml
index 8f1bf8655..405281cb8 100644
--- a/doc/reference_operator.xml
+++ b/doc/reference_operator.xml
@@ -144,7 +144,7 @@ FROM ( VALUES
<note><para>This operand is intended to be used internally by BRIN indexes, more
than by users.</para></note>
- <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced. Requires PostgreSQL 9.5+.</para>
+ <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced.</para>
<para>&curve_support;</para>
<para>&P_support;</para>
</refsection>
@@ -212,7 +212,7 @@ SELECT ST_Point(1,1) && ST_MakeBox2D(ST_Point(0,0), ST_Point(2,2)) AS overlaps;
<note><para>This operand is intended to be used internally by BRIN indexes, more
than by users.</para></note>
- <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced. Requires PostgreSQL 9.5+.</para>
+ <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced.</para>
<para>&curve_support;</para>
<para>&P_support;</para>
</refsection>
@@ -280,7 +280,7 @@ SELECT ST_MakeBox2D(ST_Point(0,0), ST_Point(2,2)) && ST_Point(1,1) AS overlaps;
<note><para>This operator is intended to be used internally by BRIN indexes, more
than by users.</para></note>
- <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced. Requires PostgreSQL 9.5+.</para>
+ <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced.</para>
<para>&curve_support;</para>
<para>&P_support;</para>
</refsection>
@@ -438,7 +438,7 @@ FROM ( VALUES
<note><para>This operator is intended to be used internally by BRIN indexes, more
than by users.</para></note>
- <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced. Requires PostgreSQL 9.5+.</para>
+ <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced.</para>
<para>&curve_support;</para>
<para>&P_support;</para>
<para>&T_support;</para>
@@ -502,7 +502,7 @@ SELECT ST_MakePoint(1,1,1) &&& ST_3DMakeBox(ST_MakePoint(0,0,0), ST_MakePoint(2,
<note><para>This operator is intended to be used internally by BRIN indexes, more
than by users.</para></note>
- <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced. Requires PostgreSQL 9.5+.</para>
+ <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced.</para>
<para>&curve_support;</para>
<para>&P_support;</para>
<para>&T_support;</para>
@@ -566,7 +566,7 @@ SELECT ST_3DMakeBox(ST_MakePoint(0,0,0), ST_MakePoint(2,2,2)) &&& ST_MakePoint(1
<note><para>This operator is intended to be used internally by BRIN indexes, more
than by users.</para></note>
- <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced. Requires PostgreSQL 9.5+.</para>
+ <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced.</para>
<para>&curve_support;</para>
<para>&P_support;</para>
<para>&T_support;</para>
@@ -1258,7 +1258,7 @@ FROM
<note><para>This operand is intended to be used internally by BRIN indexes, more
than by users.</para></note>
- <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced. Requires PostgreSQL 9.5+.</para>
+ <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced.</para>
<para>&curve_support;</para>
<para>&P_support;</para>
</refsection>
@@ -1324,7 +1324,7 @@ FROM
<note><para>This operand is intended to be used internally by BRIN indexes, more
than by users.</para></note>
- <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced. Requires PostgreSQL 9.5+.</para>
+ <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced.</para>
<para>&curve_support;</para>
<para>&P_support;</para>
</refsection>
@@ -1390,7 +1390,7 @@ FROM
<note><para>This operand is intended to be used internally by BRIN indexes, more
than by users.</para></note>
- <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced. Requires PostgreSQL 9.5+.</para>
+ <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced.</para>
<para>&curve_support;</para>
<para>&P_support;</para>
</refsection>
@@ -1664,7 +1664,7 @@ FROM
<note><para>This operand is intended to be used internally by BRIN indexes, more
than by users.</para></note>
- <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced. Requires PostgreSQL 9.5+.</para>
+ <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced.</para>
<para>&curve_support;</para>
<para>&P_support;</para>
</refsection>
@@ -1730,7 +1730,7 @@ FROM
<note><para>This operand is intended to be used internally by BRIN indexes, more
than by users.</para></note>
- <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced. Requires PostgreSQL 9.5+.</para>
+ <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced.</para>
<para>&curve_support;</para>
<para>&P_support;</para>
</refsection>
@@ -1796,7 +1796,7 @@ FROM
<note><para>This operand is intended to be used internally by BRIN indexes, more
than by users.</para></note>
- <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced. Requires PostgreSQL 9.5+.</para>
+ <para role="availability" conformance="2.3.0">Availability: 2.3.0 support for Block Range INdexes (BRIN) was introduced.</para>
<para>&curve_support;</para>
<para>&P_support;</para>
</refsection>
@@ -1952,21 +1952,19 @@ Returns the 2D distance between A and B.
<title>Description</title>
<para>
-The <varname><-></varname> operator returns the 2D distance between
+ The <varname><-></varname> operator returns the 2D distance between
two geometries. Used in the "ORDER BY" clause provides index-assisted
-nearest-neighbor result sets. For PostgreSQL below 9.5 only gives
-centroid distance of bounding boxes and for PostgreSQL 9.5+, does true
-KNN distance search giving true distance between geometries, and distance
-sphere for geographies.
+nearest-neighbor result sets with true KNN distance search for geometries,
+and distance on the sphere for geographies.
</para>
<note><para>This operand will make use of 2D GiST indexes that may be available on the geometries. It is different from other operators that use spatial indexes in that the spatial index is only used when the operator is in the ORDER BY clause.</para></note>
<note><para>Index only kicks in if one of the geometries is a constant (not in a subquery/cte). e.g. 'SRID=3005;POINT(1011102 450541)'::geometry instead of a.geom</para></note>
<para>Refer to <link xlink:href="https://postgis.net/workshops/postgis-intro/knn.html">PostGIS workshop: Nearest-Neighbor Searching</link> for a detailed example.</para>
- <para role="enhanced" conformance="2.2.0">Enhanced: 2.2.0 -- True KNN ("K nearest neighbor") behavior for geometry and geography for PostgreSQL 9.5+. Note for geography KNN is based on sphere rather than spheroid. For PostgreSQL 9.4 and below, geography support is new but only supports centroid box.</para>
- <para role="changed" conformance="2.2.0">Changed: 2.2.0 -- For PostgreSQL 9.5 users, old Hybrid syntax may be slower, so you'll want to get rid of that hack if you are running your code only on PostGIS 2.2+ 9.5+. See examples below.</para>
- <para role="availability" conformance="2.0.0">Availability: 2.0.0 -- Weak KNN provides nearest neighbors based on geometry centroid distances instead of true distances. Exact results for points, inexact for all other types. Available for PostgreSQL 9.1+</para>
+ <para role="enhanced" conformance="2.2.0">Enhanced: 2.2.0 -- True KNN ("K nearest neighbor") behavior for geometry and geography. Note for geography KNN is based on sphere rather than spheroid.</para>
+ <para role="changed" conformance="2.2.0">Changed: 2.2.0 -- Old hybrid-syntax workarounds may be slower once true KNN is available. See examples below.</para>
+ <para role="availability" conformance="2.0.0">Availability: 2.0.0 -- Weak KNN provides nearest neighbors based on geometry centroid distances instead of true distances. Exact results for points, inexact for all other types.</para>
</refsection>
@@ -2018,9 +2016,9 @@ ORDER BY geom <-> 'SRID=3005;POINT(1011102 450541)'::geometry limit 10;
If you run "EXPLAIN ANALYZE" on the two queries you would see a performance improvement for the second.
</para>
-<para>
-For users running with PostgreSQL < 9.5, use a hybrid query to find the true nearest neighbors. First a CTE query using the index-assisted KNN, then an exact query to get correct ordering:
-</para>
+ <para>
+When a plan cannot produce exact distances directly, use a hybrid query to find the true nearest neighbors. First a CTE query using the index-assisted KNN, then an exact query to get correct ordering:
+ </para>
<programlisting><![CDATA[
WITH index_query AS (
SELECT ST_Distance(geom, 'SRID=3005;POINT(1011102 450541)'::geometry) as d,edabbr, vaabbr
@@ -2091,13 +2089,13 @@ The <varname>|=|</varname> operator returns the 3D distance between
two trajectories (See <xref linkend="ST_IsValidTrajectory"/>).
This is the same as <xref linkend="ST_DistanceCPA"/> but as an operator
it can be used for doing nearest neighbor searches using an N-dimensional
-index (requires PostgreSQL 9.5.0 or higher).
+index.
</para>
<note><para>This operand will make use of ND GiST indexes that may be available on the geometries. It is different from other operators that use spatial indexes in that the spatial index is only used when the operator is in the ORDER BY clause.</para></note>
<note><para>Index only kicks in if one of the geometries is a constant (not in a subquery/cte). e.g. 'SRID=3005;LINESTRINGM(0 0 0,0 0 1)'::geometry instead of a.geom</para></note>
- <para role="availability" conformance="2.2.0.">Availability: 2.2.0. Index-supported only available for PostgreSQL 9.5+</para>
+ <para role="availability" conformance="2.2.0.">Availability: 2.2.0.</para>
</refsection>
@@ -2165,14 +2163,14 @@ Returns the 2D distance between A and B bounding boxes.
<refsection>
<title>Description</title>
- <para>The <varname><#></varname> operator returns distance between two floating point bounding boxes, possibly reading them from a spatial index (PostgreSQL 9.1+ required). Useful for doing nearest neighbor <emphasis role="strong">approximate</emphasis> distance ordering.</para>
+ <para>The <varname><#></varname> operator returns distance between two floating point bounding boxes, possibly reading them from a spatial index. Useful for doing nearest neighbor <emphasis role="strong">approximate</emphasis> distance ordering.</para>
<note><para>This operand will make use of any indexes that may be available on the
geometries. It is different from other operators that use spatial indexes in that the spatial index is only used when the operator
is in the ORDER BY clause.</para></note>
<note><para>Index only kicks in if one of the geometries is a constant e.g. ORDER BY (ST_GeomFromText('POINT(1 2)') <#> geom) instead of g1.geom <#>.</para></note>
- <para role="availability" conformance="2.0.0">Availability: 2.0.0 -- KNN only available for PostgreSQL 9.1+</para>
+ <para role="availability" conformance="2.0.0">Availability: 2.0.0.</para>
</refsection>
@@ -2266,7 +2264,7 @@ subquery/cte). e.g. 'SRID=3005;POINT(1011102 450541)'::geometry instead
of a.geom
</para></note>
- <para role="availability" conformance="2.2.0">Availability: 2.2.0 -- KNN only available for PostgreSQL 9.1+</para>
+ <para role="availability" conformance="2.2.0">Availability: 2.2.0.</para>
</refsection>
diff --git a/doc/reference_output.xml b/doc/reference_output.xml
index 7d08befec..795ff71a5 100644
--- a/doc/reference_output.xml
+++ b/doc/reference_output.xml
@@ -264,8 +264,8 @@ F000000000000000000000000000000000000000000000000');
</note>
<note>
- <para>The default behavior in PostgreSQL 9.0 has been changed to output bytea in hex encoding.
- If your GUI tools require the old behavior, then SET bytea_output='escape' in your database.</para>
+ <para>PostgreSQL outputs <varname>bytea</varname> values in hex encoding by default.
+ If your GUI tools require the old behavior, then SET <code>bytea_output='escape'</code> in your database.</para>
</note>
<para role="enhanced" conformance="2.0.0">Enhanced: 2.0.0 support for Polyhedral surfaces, Triangles and TIN was introduced.</para>
diff --git a/doc/reference_raster.xml b/doc/reference_raster.xml
index 10559043e..79d82cec2 100644
--- a/doc/reference_raster.xml
+++ b/doc/reference_raster.xml
@@ -1612,8 +1612,7 @@ FROM ST_BandMetadata(
<programlisting>
-- Aggregate the 1st band of a table of like rasters into a single raster
-- with as many bands as there are test_types and as many rows (new rasters) as there are mice
--- NOTE: The ORDER BY test_type is only supported in PostgreSQL 9.0+
--- for 8.4 and below it usually works to order your data in a subselect (but not guaranteed)
+-- NOTE: The ORDER BY test_type clause relies on aggregate ORDER BY support.
-- The resulting raster will have a band for each test_type alphabetical by test_type
-- For mouse lovers: No mice were harmed in this exercise
SELECT
@@ -4724,7 +4723,7 @@ SELECT ST_AsText(ST_PixelAsCentroid(rast, 1, 1)) FROM dummy_rast WHERE rid = 1;
<refsection>
<title>Examples</title>
- <programlisting> --LATERAL syntax requires PostgreSQL 9.3+
+ <programlisting> -- Uses LATERAL syntax
SELECT x, y, val, ST_AsText(geom)
FROM (SELECT dp.* FROM dummy_rast, LATERAL ST_PixelAsCentroids(rast, 1) AS dp WHERE rid = 2) foo;
x | y | val | st_astext
@@ -7261,7 +7260,7 @@ SELECT rid, (meta).* FROM bar
<note>
<para>
- If you find your transformation support is not working right, you may need to set the environment variable PROJSO to the .so or .dll projection library your PostGIS is using. This just needs to have the name of the file. So for example on windows, you would in Control Panel -> System -> Environment Variables add a system variable called <varname>PROJSO</varname> and set it to <varname>libproj.dll</varname> (if you are using proj 4.6.1). You'll have to restart your PostgreSQL service/daemon after this change.
+ If you find your transformation support is not working right, you may need to set the environment variable PROJSO to the projection library your PostGIS build is using. This just needs to have the name of the file. So for example on windows, you would in Control Panel -> System -> Environment Variables add a system variable called <varname>PROJSO</varname> and set it to <varname>libproj.dll</varname>. You'll have to restart your PostgreSQL service/daemon after this change.
</para>
</note>
@@ -10446,7 +10445,7 @@ WHERE t1.rid = 1
AND t2.rid = 2
</programlisting>
- <para>Complete example of tiles of a coverage with neighborhood. This query only works with PostgreSQL 9.1 or higher.</para>
+ <para>Complete example of tiles of a coverage with neighborhood.</para>
<programlisting>
WITH foo AS (
SELECT 0 AS rid, ST_AddBand(ST_MakeEmptyRaster(2, 2, 0, 0, 1, -1, 0, 0, 0), 1, '16BUI', 1, 0) AS rast UNION ALL
@@ -10478,7 +10477,7 @@ WHERE t1.rid = 4
GROUP BY t1.rid, t1.rast
</programlisting>
- <para>Example like the prior one for tiles of a coverage with neighborhood but works with PostgreSQL 9.0.</para>
+ <para>Example like the prior one for tiles of a coverage with neighborhood but using only basic SQL features.</para>
<programlisting>
WITH src AS (
SELECT 0 AS rid, ST_AddBand(ST_MakeEmptyRaster(2, 2, 0, 0, 1, -1, 0, 0, 0), 1, '16BUI', 1, 0) AS rast UNION ALL
@@ -13350,7 +13349,7 @@ FROM foo
<refsection>
<title>Examples: Variant 2</title>
- <para>Complete example of tiles of a coverage. This query only works with PostgreSQL 9.1 or higher.</para>
+ <para>Complete example of tiles of a coverage.</para>
<programlisting>
WITH foo AS (
@@ -13498,7 +13497,7 @@ FROM foo
<refsection>
<title>Examples: Variant 2</title>
- <para>Complete example of tiles of a coverage. This query only works with PostgreSQL 9.1 or higher.</para>
+ <para>Complete example of tiles of a coverage.</para>
<programlisting>
WITH foo AS (
@@ -13681,7 +13680,7 @@ FROM foo
<refsection>
<title>Examples: Variant 2</title>
- <para>Complete example of tiles of a coverage. This query only works with PostgreSQL 9.1 or higher.</para>
+ <para>Complete example of tiles of a coverage.</para>
<programlisting>
WITH foo AS (
diff --git a/doc/using_postgis_dataman.xml b/doc/using_postgis_dataman.xml
index 9d281193a..896184c0f 100644
--- a/doc/using_postgis_dataman.xml
+++ b/doc/using_postgis_dataman.xml
@@ -630,8 +630,7 @@ geometry = ST_GeomFromEWKT(text EWKT);</programlisting>
<para>Like the geometry data type, geography data is associated
with a spatial reference system via a spatial reference system identifier (SRID).
Any geodetic (long/lat based) spatial reference system defined in the <varname>spatial_ref_sys</varname> table can be used.
- (Prior to PostGIS 2.2, the geography type supported only WGS 84 geodetic (SRID:4326)).
- You can add your own custom geodetic spatial reference system as described in <xref linkend="user-spatial-ref-sys"/>.</para>
+ You can add your own custom geodetic spatial reference system as described in <xref linkend="user-spatial-ref-sys"/>.</para>
<para>For all spatial reference systems the units returned by measurement functions
(e.g. <xref linkend="ST_Distance"/>, <xref linkend="ST_Length"/>, <xref linkend="ST_Perimeter"/>, <xref linkend="ST_Area"/>)
@@ -1749,8 +1748,7 @@ CREATE INDEX my_special_pois_geom_gist_nd
-- to make the column typmod based.
SELECT populate_geometry_columns('myschema.my_special_pois'::regclass);
--- If you are using PostGIS 2.0 and for whatever reason, you
--- you need the constraint based definition behavior
+-- To retain the constraint-based definition behavior
-- (such as case of inherited tables where all children do not have the same type and srid)
-- set optional use_typmod argument to false
SELECT populate_geometry_columns('myschema.my_special_pois'::regclass, false); </programlisting>
@@ -2436,7 +2434,7 @@ pgsql2shp [<options>] <database> <query>
<title>BRIN Indexes</title>
<para>BRIN stands for "Block Range Index". It is a general-purpose
- index method introduced in PostgreSQL 9.5.
+ index method provided by PostgreSQL.
BRIN is a <emphasis>lossy</emphasis>
index method, meaning that a secondary check is required to confirm
that a record matches a given search condition
diff --git a/doc/using_raster_dataman.xml b/doc/using_raster_dataman.xml
index e225e0020..ef79c1164 100644
--- a/doc/using_raster_dataman.xml
+++ b/doc/using_raster_dataman.xml
@@ -583,7 +583,7 @@ if (!empty( $_REQUEST['srid'] ) && is_numeric( $_REQUEST['srid']) ){
$input_srid = intval($_REQUEST['srid']);
}
else { $input_srid = 26986; }
-/** The set bytea_output may be needed for PostgreSQL 9.0+, but not for 8.4 **/
+/** The set bytea_output ensures bytea values are returned using escape format. **/
$sql = "set bytea_output='escape';
SELECT ST_AsPNG(ST_Transform(
ST_AddBand(ST_Union(rast,1), ARRAY[ST_Union(rast,2),ST_Union(rast,3)])
-----------------------------------------------------------------------
Summary of changes:
doc/administration.xml | 10 ++++----
doc/database_tuning.xml | 17 +++++++-------
doc/installation.xml | 6 ++---
doc/reference_constructor.xml | 2 +-
doc/reference_management.xml | 4 ++--
doc/reference_operator.xml | 54 +++++++++++++++++++++----------------------
doc/reference_output.xml | 4 ++--
doc/reference_raster.xml | 17 +++++++-------
doc/using_postgis_dataman.xml | 8 +++----
doc/using_raster_dataman.xml | 2 +-
10 files changed, 59 insertions(+), 65 deletions(-)
hooks/post-receive
--
PostGIS
More information about the postgis-tickets
mailing list