On Tue, Jul 5, 2011 at 10:26 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis <pg...@j-davis.com> wrote: >> On Tue, 2011-07-05 at 10:06 -0400, Robert Haas wrote: >>> > But if it's actually better, we should do it. If an intermediate type >>> > seems to be problematic, or if people think it's strange to require >>> > casting, then I think this is reasonable. >>> >>> I don't understand how the bespoke syntax avoids the need for a cast? >> >> It doesn't, it just avoids the need for an intermediate type. >> >> What I meant was that it might be strange to require a cast on the >> result of a function call, because we don't really do that anywhere >> else. Florian pointed out that it's common to require casting the >> ARRAY[] constructor, so that has more of a precedent. I'm not really >> sure how much that matters. >> >> I'm OK with the intermediate type, but Florian seems skeptical of that >> idea. > > How about the idea of creating a family of four constructor functions > for each new range type? The functions would be named after the range > type, with "_cc", "_co", "_oc", and "_oo" appended. So, then, instead > of writing: > > RANGE(1,8,'c','o')::int8range > > ...or somesuch, you could just say: > > int8range_co(1,8) > > ...which is both more compact and less ugly, IMHO, and seems to > circumvent all the type system problems as well.
+1 on this (so you wouldn't even then directly cast to a range?) merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers