On Tue, Jul 5, 2011 at 10:26 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis <pgsql@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