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.
> 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.
Also, if someone has an idea for another constructor, like the one you
mention above: range(1,8,'c','o')
then they have to create it for every range type, and they can't
anticipate new range types that someone might create. In other words,
the constructors wouldn't benefit from the polymorphism. However, if we
used an intermediate type, then they could create the above constructor
and it would work for any range type automatically.
I don't object to this idea, but we'll need to come up with a pretty
exhaustive list of possibly-useful constructors.
Regards,Jeff Davis