On Tue, 2011-06-28 at 22:20 +0200, Florian Pflug wrote: > Hm, so RANGEINPUT would actually be what was previously discussed as > the "range as a pair of bounds" definition, as opposed to the > "range as a set of values" definition. So essentially we'd add a > second concept of what a "range" is to work around the range input > troubles. > > I believe if we go that route we should make RANGEINPUT a full-blown > type, having "pair of bound" semantics. Adding a lobotomized version > just for the sake of range input feels a bit like a kludge to me.
I think David Wheeler was trying to make a similar point, but I'm still not convinced. It's not a pair, because it can be made up of 0, 1, or 2 scalar values (unless you count infinity as one of those values, in which case 0 or 2). And without ordering, it's not clear that those values are really "bounds". The type needs to: * represent two values, either of which might be a special infinite value * represent the value "empty" * represent inclusivity/exclusivity of both values and those things seem fairly specific to ranges, so I don't really see what other use we'd have for such a type. But I'm open to suggestion. I don't think that having an extra type around is so bad. It solves a lot of problems, and doesn't seem like it would get in the way. And it's only for the construction of ranges out of scalars, which seems like the most natural place where a cast might be required (similar to casting an unknown literal, which is fairly common). > Alternatively, we could replace RANGEINPUT simply with ANYARRAY, > and add functions ANYRANGE->ANYRANGE which allow specifying the > bound operator (<, <= respectively >,>=) after construction. > > So you'd write (using the functions-as-fields syntax I believe > we support) > (ARRAY[1,2]::int8range).left_open.right_closed for '(1,2]' > and > ARRAY[NULL,2]::int8range for '[-inf,2]' I think we can rule this one out: * The functions-as-fields syntax is all but deprecated (or should be) * That's hardly a readability improvement * It still suffers similar problems as casting back and forth to text: ANYARRAY is too general, doesn't really take advantage of the type system, and not a great fit anyway. > All assuming that modifying the type system to support polymorphic > type resolution based on the return type is out of the question... ;-) It's still not out of the question, but I thought that the intermediate type would be a less-intrusive alternative (and Robert seemed concerned about how intrusive it was). There also might be a little more effort educating users if we selected the function based on the return type, because they might think that casting the inputs explicitly would be enough to get it to pick the right function. If it were a new syntax like RANGE::int8range, then I think it would be easier to understand. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers