On Tue, Jul 5, 2011 at 12:23 PM, Merlin Moncure <mmonc...@gmail.com> wrote: > 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?)
You wouldn't need to, because these functions would be declared to return the range type. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
