On Wed, 2011-11-23 at 22:33 -0500, Tom Lane wrote: > * 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.
That seems solvable, unless I'm missing something. > * 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. That seems a little more challenging. > 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. An interesting approach. I wonder if there would be a reason to tie such types together for a reason other than just the canonical function? Would you have to define everything in terms of the continuous range, or could it be a constraint hierarchy; e.g. a step size 100 is based on a step size of 10 which is based on numeric? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers