Re: Document "59.2. Built-in Operator Classes" have a clerical error?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, osdba <mailtch(at)163(dot)com>, pgsql-docs(at)postgresql(dot)org, jkatz(at)postgresql(dot)org
Subject: Re: Document "59.2. Built-in Operator Classes" have a clerical error?
Date: 2020-08-26 23:19:09
Message-ID: 2985974.1598483949@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2020-Aug-26, Bruce Momjian wrote:
>> Stupid question, but do we think the average Postgres user can
>> understand this issue. I am having trouble myself.

> The only reason I think it's worth pointing out, is that the opclass
> name is something you can use in CREATE INDEX, while the opfamily name
> cannot be used there. The original tables can be used for that purpose,
> but the patched tables cannot.

With one eye on the PDF width issue, I propose that we not draw
the distinction, but just list all the relevant operators for each
opclass (its native ones, plus the applicable "loose" operators).
Then we only need two columns, opclass and operators.

regards, tom lane

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Bruce Momjian 2020-08-27 02:38:30 Re: Add comma after e.g. and i.e.?
Previous Message Bruce Momjian 2020-08-26 23:09:04 Re: 35.9.2. Base Types in C-Language Functions