Re: create opclass documentation outdated

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Emre Hasegeli <emre@hasegeli.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Julien Rouhaud <julien.rouhaud@dalibo.com>, Vik Fearing <vik@2ndquadrant.fr>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-03-10T16:02:45Z
Lists: pgsql-hackers
Alvaro Herrera wrote:

> Hmm, but if we ever add support for other types in inclusion as you
> describe, we will need STORAGE, no?  I think it's unfortunate that the
> code currently uses the field where it's not really necessary, but
> harmless; if people break their systems by introducing bogus optypes,
> it's their fault.  We can discuss improving this in the future, but in
> the back branches it seems fine to leave it as is.

Hypothetical situation where a different storage type might be useful
with minmax: you store int2 values containing ln() of a numeric column.
(Not sure that there's any actual situation for people to store data
where this is valuable; consider astronomical distances, for example.)
You'd need to have support for a "cast" method that takes the values
from the ScanKey and applies ln() to them before doing the comparisons,
but it seems a reassonable setup.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Commits

  1. Document BRIN a bit more thoroughly