I wrote:
> However, what I'm on about right at the moment is that I don't think
> there should be any delta in that test at all. As far as I can see,
> the design idea here is that multiranges will be automatically created
> over range types, and the user doesn't need to do that. To my mind,
> that means that they're an implementation detail and should not show up as
> separately-owned objects, any more than an autogenerated array type does.
Actually ... have you given any thought to just deciding that ranges and
multiranges are the same type? That is, any range can now potentially
contain multiple segments? That would eliminate a whole lot of the
tedious infrastructure hacking involved in this patch, and let you focus
on the actually-useful functionality.
It's possible that this is a bad idea. It bears a lot of similarity,
I guess, to the way that Postgres doesn't consider arrays of different
dimensionality to be distinct types. That has some advantages but it
surely also has downsides. I think on the whole the advantages win,
and I feel like that might also be the case here.
The gating requirement for this would be to make sure that a plain
range and a multirange can be told apart by contents. The first idea that
comes to mind is to repurpose the allegedly-unused RANGE_xB_NULL bits in
the flag byte at the end of the datum. If one of them is set, then it's a
multirange, and we use a different interpretation of the bytes between the
type OID and the flag byte.
Assuming that that's ok, it seems like we could consider the traditional
range functions like lower() and upper() to report on the first or last
range bound in a multirange --- essentially, they ignore any "holes"
that exist inside the range. And the new functions for multiranges
act much like array slicing, in that they give you back pieces of a range
that aren't actually of a distinct type.
regards, tom lane