Obstacles to user-defined range canonicalization functions

I got religion this evening about the potential usefulness of
user-defined canonicalization functions --- the example that did it for
me was thinking about a range type over timestamp that quantizes
boundaries to hours, or half hours, or 15 minutes, or any scheduling
unit that is standard in a particular environment. In that sort of
situation you really want a discrete range type, which the standard
tsrange type is not. So how hard is it to build a user-defined
canonicalization function to support such an application? The logic
doesn't seem terribly difficult ... but *you have to write the darn
thing in C*. There are two reasons why:

* The underlying range_serialize function is only exposed at the C
level. If you try to write something in, say, plpgsql then you are
going to end up going through range_constructorN or range_in to produce
your result value, and those call the type's canonical function.
Infinite recursion, here we come.

* The only way to create a canonicalization function in advance of
declaring the range type is to declare it against a shell type. But the
PL languages all reject creating PL functions that take or return a
shell type. Maybe we could relax that, but it's nervous-making, and
anyway the first problem still remains.

Now you could argue that for performance reasons everybody should write
their canonicalization functions in C anyway, but I'm not sure I buy
that --- at the very least, it'd be nice to write the functions in
something higher-level while prototyping.

I have no immediate proposal for how to fix this, but I think it's
something we ought to think about.

One possibility that just came to me is to decree that every discrete
range type has to be based on an underlying continuous range type (with
all the same properties except no canonicalization function), and then
the discrete range's canonicalization function could be declared to take
and return the underlying range type instead of the discrete type
itself. Haven't worked through the details though.

regards, tom lane