Re: Range Types, constructors, and the type system

On Tue, Jul 5, 2011 at 12:23 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Tue, Jul 5, 2011 at 10:26 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis <pgsql(at)j-davis(dot)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