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