Re: "box" type description

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: myon(at)debian(dot)org
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: "box" type description
Date: 2021-03-31 02:32:40
Message-ID: 20210331.113240.1063412187478637420.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Mon, 29 Mar 2021 22:44:29 +0200, Christoph Berg <myon(at)debian(dot)org> wrote in
> I believe the "box" type description is slightly incorrect:
>
> # \dT box
> Liste der Datentypen
> Schema │ Name │ Beschreibung
> ────────────┼──────┼──────────────────────────────────────────
> pg_catalog │ box │ geometric box '(lower left,upper right)'
>
> While the syntax '((3,4),(1,2))'::box works, the canonical spelling is
> '(3,4),(1,2)' and hence the description should be:
> geometric box '(lower left),(upper right)'

Maybe the reason you think so is that a box is printed in that format.

postgres=# select '((1,1),(2,2))'::box;
box
-------------
(2,2),(1,1)
(1 row)

It doesn't use the word "canonical", but the documentation is saying
that it is the output format. So I think you're right in that point.

https://www.postgresql.org/docs/13/datatype-geometric.html

Table 8.20. Geometric Types

point 16 bytes Point on a plane (x,y)
line 32 bytes Infinite line {A,B,C}
lseg 32 bytes Finite line segment ((x1,y1),(x2,y2))
box 32 bytes Rectangular box ((x1,y1),(x2,y2))
path 16+16n bytes Closed path (similar to polygon) ((x1,y1),...)
path 16+16n bytes Open path [(x1,y1),...]
polygon 40+16n bytes Polygon (similar to closed path) ((x1,y1),...)
circle 24 bytes Circle <(x,y),r> (center point and radius)

Similary, lseg seems inconsistent... (It is correctly described in
later sections.)

select '(1,1),(2,2)'::lseg; => [(1,1),(2,2)]

Surely it would be better that the documentation is consistent with
the output function. Perhaps we prefer to fix documentation rather
than to fix implementation to give impacts on applications that may
exist. (I don't like the notation since the representation of box
doesn't look like one object, though..)

Returing to the description of pg_types, it should be changed like
this following the discussion here.

- pg_catalog | box | geometric box '(lower left,upper right)'
+ pg_catalog | box | geometric box 'lower left,upper right'

But I find it hard to read. I fixed it instead as the following in the
attached. However, it might rather be better not changing it..

+ pg_catalog | box | geometric box 'pt-lower-left,pt-upper-right'

I added a space after commas, since point has it and (I think) it is
easier to read having the ones.

Is there any opinions?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
fix_geom_type_description.patch text/x-patch 2.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2021-03-31 02:37:33 Re: making update/delete of inheritance trees scale better
Previous Message James Hilliard 2021-03-31 02:19:22 Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.