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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
