Re: extended operator classes vs. type interfaces

On 04/09/2010 07:33 AM, Robert Haas wrote:
> On Fri, Apr 9, 2010 at 7:55 AM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
>> 'tagging' a datatype as a lineair order, it could automatically have a range
>> type defined on it, like done for the array types currently.
>
> The way we've handled array types is, quite frankly, horrible. It's
> bad enough that we now have two catalog entries in pg_type for each
> base type; what's even worse is that if we actually wanted to enforce
> things like the number of array dimensions we'd need even more - say,
> seven per base type, one for the base type itself, one for a
> one-dimensional array, one for a two-dimensional array, one for a
> three-dimensional array. And then if we want to support range types
> that's another one for every base type, maybe more if there's more
> than one kind of range over a base type. It's just not feasible to
> handle derived types in a way that require a new instance of each base
> type to be created for each kind of derived type. It scales as
> O(number of base types * number of kinds of derived type), and that
> rapidly gets completely out of hand

Perhaps off the original topic (and thinking out loud), but I agree with
you on the handling of array types. I have long thought (and at least
once played with the idea) that a single array type, anyarray, made up
of elements, anyelement, could be made to work. Further, anyelement
should be defined to be any valid existing type, including anyarray.
Essentially, at least by my reading of the SQL spec, a multidimensional
array ought to be an array of arrays, which is different in subtle ways
from what we have today.

Joe