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.
(compare-values type-name op a b)a op b for two canonical values of type-name. Only called for the
combinations comparison-exists? admits.
`a op b` for two canonical values of `type-name`. Only called for the combinations `comparison-exists?` admits.
(comparison-exists? type-name op)Does PostgreSQL have op for two operands of type-name?
Does PostgreSQL have `op` for two operands of `type-name`?
Which of = <> < > <= >= PostgreSQL actually has for each type, read
off pg_operator. ~= (same as) is left out: it does not parse here
yet. Note the gaps -- box and path have no <>, point has no =,
and polygon has none of the six.
Which of `= <> < > <= >=` PostgreSQL actually has for each type, read off pg_operator. `~=` (`same as`) is left out: it does not parse here yet. Note the gaps -- box and path have no `<>`, point has no `=`, and polygon has none of the six.
(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.
(geometric-length type-name s)lseg_length / path_length: the sum of the segment lengths, which
length() answered with the CHARACTER COUNT of the canonical text --
13 for [(0,0),(3,4)], where PostgreSQL says 5. A plausible number
with no error, which is the worst shape a wrong answer takes.
`lseg_length` / `path_length`: the sum of the segment lengths, which `length()` answered with the CHARACTER COUNT of the canonical text -- 13 for `[(0,0),(3,4)]`, where PostgreSQL says 5. A plausible number with no error, which is the worst shape a wrong answer takes.
(spatial-op op lt rt)The implementation of [op lt rt], or nil when PostgreSQL has the
operator and this does not.
The implementation of `[op lt rt]`, or nil when PostgreSQL has the operator and this does not.
(spatial-op-known? op lt rt)Is [op left-type right-type] an operator PostgreSQL has for these
geometric types -- whether or not we implement it?
Is `[op left-type right-type]` an operator PostgreSQL has for these geometric types -- whether or not we implement it?
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 |