Input and output for PostgreSQL's geometric types (geo_ops.c).
These were accepted as whatever text was written: 'garbage'::point
answered garbage, a value that is not a point, in a point column,
reported as success. That is the passthrough class this campaign
exists to remove, and it applied to all seven of them.
Values are held as their CANONICAL text, which is what PostgreSQL
prints, so storage, comparison and rendering all agree. Canonical
matters beyond tidiness: box sorts its corners so the upper-right
comes first, so '(1,2),(3,4)' and '(3,4),(1,2)' are the same box
and must be the same text.
The operators (&&, <->, ~=, @>) are a separate matter; this
is input, output and identity only.
Input and output for PostgreSQL's geometric types (geo_ops.c). These were accepted as whatever text was written: `'garbage'::point` answered `garbage`, a value that is not a point, in a point column, reported as success. That is the passthrough class this campaign exists to remove, and it applied to all seven of them. Values are held as their CANONICAL text, which is what PostgreSQL prints, so storage, comparison and rendering all agree. Canonical matters beyond tidiness: `box` sorts its corners so the upper-right comes first, so `'(1,2),(3,4)'` and `'(3,4),(1,2)'` are the same box and must be the same text. The operators (`&&`, `<->`, `~=`, `@>`) are a separate matter; this is input, output and identity only.
(geometric-in type-name v)Canonical text for v as type-name, or 22P02 when it is not one.
Canonical text for `v` as `type-name`, or 22P02 when it is not one.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |