On Mon, 2011-06-27 at 14:50 -0400, Robert Haas wrote: > Couldn't we also do neither of these things? I mean, presumably > '[1,10]'::int8range had better work.
I think that if we combine this idea with Florian's "PAIR" suggestion here: http://archives.postgresql.org/message-id/ad4fc75d-db99-48ed-9082-52ee3a4d7...@phlo.org then I think we have a solution. If we add a type RANGEINPUT that is not a pseudotype, we can use that as an intermediate type that is returned by range constructors. Then, we add casts from RANGEINPUT to each range type. That would allow range(1,2)::int8range to work without changing the type system around, because range() would have the signature: range(ANYELEMENT, ANYELEMENT) -> RANGEINPUT and then the cast would change it into an int8range. But we only need the one cast per range type, and we can also support all of the other kinds of constructors like: range_cc(ANYELEMENT, ANYELEMENT) -> RANGEINPUT range_linf_c(ANYELEMENT) -> RANGEINPUT without additional hassle. The RANGEINPUT type itself would hold similar information to actual range types: the subtype OID (instead of the range type, because it's not a range yet), optionally the two bounds (depending on the flags), and the flags byte. The cast to a real range type would read the subtype, and try to coerce the bounds to the subtype of the range you're casting to, set the range type oid, leave the flags byte the same, and it's done. So, in effect, RANGEINPUT is a special type used only for range constructors. If someone tried to output it, it would throw an exception, and we'd even have enough information at that point to print a nice error message with a hint. Actually, this is pretty much exactly Florian's idea (thanks again, Florian), but at the time I didn't like it because "pair" didn't capture everything that I wanted to capture, like infinite bounds, etc. But there's no reason that it can't, and your point made me realize that -- you are effectively just using TEXT as the intermediate type (which works, but has some undesirable characteristics). Do we think that this is a good way forward? The only thing I can think of that's undesirable is that it's not normal to be required to cast the result of a function, and might be slightly difficult to explain in the documentation in a straightforward way. 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
