On Tue, Jul 5, 2011 at 12:54 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> On Tue, 2011-07-05 at 11:26 -0400, Robert Haas wrote:
>> 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
>
> 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...
>> int8range_co(1,8)
>>
>> ...which is both more compact and less ugly, IMHO, and seems to
>> circumvent all the type system problems as well.
>
> I brought that up before:
> http://archives.postgresql.org/pgsql-hackers/2011-06/msg02046.php
>
> It certainly circumvents the polymorphic type problems, but the problem
> is that it adds up to quite a few permutations. Not only are there
> cc/co/oc/oo, but there are also variations for infinite bounds and empty
> ranges. So I think we're talking 10+ functions per range type rather
> than 4.
OK, so let's pass the information on the bounds as a separate
argument. Like this:
int8range(1,8,'co')
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'.
For empty ranges I doubt we need a separate constructor function;
presumably the representation of an empty range is some fixed string
and users can just write 'empty'::int8range or similar.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
