From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | osdba <mailtch(at)163(dot)com>, pgsql-docs(at)postgresql(dot)org |
Subject: | Re: Document "59.2. Built-in Operator Classes" have a clerical error? |
Date: | 2020-08-04 05:56:51 |
Message-ID: | 20200804055651.GC2091@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Mon, Aug 03, 2020 at 07:23:48AM -0400, Tom Lane wrote:
> So I don't think it's a clerical error, but certainly showing these
> operators this way is none too helpful. Perhaps including the input types
> in this table (and its siblings elsewhere) would be a good thing.
Ah, thanks. I did not consider the psql shortcut. I agree that
including the input types would be a good idea. But just doing that
may not be enough IMO as the character policy used on our website for
the HTML docs makes that harder to parse. What if we switched the
third column to have one line per operator with its input type, and
use morerows to show the full set of indexable operators one opclass
is associated with? Contrary to wait events, those tables don't
change much. I am wondering as well if we should consider mentioning
\dAo on all those pages, say at the bottom of each table listing the
opclasses.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | PG Doc comments form | 2020-08-04 10:33:49 | Procedures |
Previous Message | Thomas Munro | 2020-08-04 03:12:35 | Re: "innovative Serializable Snapshot Isolation (SSI) level" |