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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
