From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>, Vik Fearing <vik(at)2ndquadrant(dot)fr>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: create opclass documentation outdated |
Date: | 2016-03-10 16:02:45 |
Message-ID: | 20160310160245.GA56414@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-03-10 16:03:29 | Re: Freeze avoidance of very large table. |
Previous Message | Corey Huinker | 2016-03-10 16:02:43 | Re: Add generate_series(date,date) and generate_series(date,date,integer) |