On Mon, 2009-12-14 at 11:10 -0800, Scott Bailey wrote:
> I was referring to the syntax for how the user actually defined an enum
> not about it's implementation. Basically what I was hoping to get out of
> this thread was whether it was better to allow the user to define their
> own range types by specifying the base type and possibly the granularity
> and default inclusiveness of the end points, or if we should just
> provide the types like period and intrange?
To be a little bit more specific about the alternatives:
1. Make a contrib module that creates a variety of range types like
PERIOD, PERIODTZ, INT4RANGE, NUMRANGE, etc. In order to support some of
the other features I intend to work on, such as a range join (e.g.
temporal join), we would need to mark an operator family to know that it
conforms to a certain strategy number convention. See:
http://archives.postgresql.org/pgsql-hackers/2009-10/msg01769.php
http://archives.postgresql.org/pgsql-hackers/2009-10/msg01441.php
2. Implement some kind of ANYRANGE type and associated operators; and
provide a way to define new range types by providing the base type,
difference type (e.g. for TIMESTAMP, the difference type would be
INTERVAL) and a couple support functions. This might be more flexible,
and it would obviate the need for marking operator families.
If the second approach seems promising, we can hammer out a real
proposal and see if it's viable.
Regards,Jeff Davis