PG Doc comments form <nore...@postgresql.org> writes:
> Hi, I am writing to suggest a couple of clarifications to "8.8. Geometric
> Types" documentation chapter.
Fair points. I am not really eager to say explicitly here that the
set of available functions varies for the different types: that seems
pretty self-evident. But your other ideas are good.
I also noted while looking at this that table 8.20 is flat out wrong
about the storage size of "line" values: they are 24 bytes each not
32. (This can be confirmed from pg_type.typlen or by looking at
struct LINE in the source code.)
How about the attached?
regards, tom lane
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 6646820d6a..a693424a69 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -3369,7 +3369,7 @@ SELECT person.name, holidays.num_weeks FROM person, holidays
</row>
<row>
<entry><type>line</type></entry>
- <entry>32 bytes</entry>
+ <entry>24 bytes</entry>
<entry>Infinite line</entry>
<entry>{A,B,C}</entry>
</row>
@@ -3413,6 +3413,11 @@ SELECT person.name, holidays.num_weeks FROM person, holidays
</tgroup>
</table>
+ <para>
+ In all these types, the individual coordinates are stored as
+ <type>double precision</type> (<type>float8</type>) numbers.
+ </para>
+
<para>
A rich set of functions and operators is available to perform various geometric
operations such as scaling, translation, rotation, and determining
@@ -3607,6 +3612,14 @@ SELECT person.name, holidays.num_weeks FROM person, holidays
within it, while a path is not.
</para>
+ <para>
+ An important implementation difference between polygons and closed
+ paths is that the stored representation of a polygon includes its
+ smallest bounding box. This speeds up certain search operations,
+ although computing the bounding box adds overhead while constructing
+ new polygons.
+ </para>
+
<para>
Values of type <type>polygon</type> are specified using any of the
following syntaxes:
