On Wed, Jul 6, 2011 at 1:19 AM, Jeff Davis <pgsql@j-davis.com> wrote:
> On Tue, 2011-07-05 at 13:06 -0400, Robert Haas wrote:
>> On Tue, Jul 5, 2011 at 12:54 PM, Jeff Davis <pgsql@j-davis.com> wrote:
>> > It would be something like: range_co(1,8)::int8range
>> >
>> > (just so we're comparing apples to apples)
>> >
>> > The intermediate type proposal doesn't require that we move the "c" and
>> > "o" into the parameter list.
>>
>> Well, you have to specify the bounds somewhere...
>
> That's true. In my example it's in the function name.
>
>> OK, so let's pass the information on the bounds as a separate
>> argument. Like this:
>>
>> int8range(1,8,'co')
>
> That has a lot going for it, in the sense that it avoids dealing with
> the type problems.
>
>> Then you can instead pass 'o' for open or 'i' for infinity (passing
>> NULL for the corresponding argument position in that case). The third
>> argument can be optional and default to 'cc'.
>
> The fact that there can be a default for the third argument makes this
> quite a lot more appealing than I had originally thought (although I
> think 'co' is the generally-accepted default).
>
> There's some slight ugliness around the NULL/infinity business, but I
> think that I could be convinced. I'd like to avoid confusion between
> NULL and infinity if possible.
I was thinking that if you passed 'i' for one of the bounds, it would
ignore the supplied argument and substitute its special infinity
value. But you'd still need to supply some argument in that position,
which could be NULL or anything else. It doesn't really seem worth
having additional constructor functions to handle the case where one
or both arguments are infinite.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
