From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Bruce Momjian <bruce@momjian.us>, Michael Paquier <michael@paquier.xyz>,
        osdba <mailtch@163.com>, pgsql-docs@postgresql.org,
        jkatz@postgresql.org
Subject: Re: Document "59.2. Built-in Operator Classes" have a clerical error?
In-reply-to: <20200826225837.GA3099@alvherre.pgsql>
References: <20200826225837.GA3099@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Wed, 26 Aug 2020 18:58:37 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2985973.1598483949.1@sss.pgh.pa.us>
Date: Wed, 26 Aug 2020 19:19:09 -0400
Message-ID: <2985974.1598483949@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.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