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
-
Document BRIN a bit more thoroughly
- c84c87ccc0e2 9.5.2 landed
- a3a8309d450f 9.6.0 landed