Scott Bailey <arta...@comcast.net> writes: > So basically I have an anyrange pseudo type with the functions prev, > next, last, etc defined. So instead of hard coding range types, we would > allow the user to define their own range types. Basically if we are able > to determine the previous and next values of the base types we'd be able > to define a range type. I'm envisioning in a manner much like defining > an enum type.
I think array types, not enums, would be a better model. The real question is how the heck granularity enters into it. Why should a range type require that? I think you are mixing up two concepts that would be better kept separate. In particular, the granularity examples you give seem to assume that the underlying datatype is exact not approximate --- which among other things will mean that it fails to work for float timestamps. Since timestamps are supposedly the main use-case, that's pretty troubling. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers