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

Reply via email to