Re: Obstacles to user-defined range canonicalization functions - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Obstacles to user-defined range canonicalization functions
Date
Msg-id 1322161312.16623.11.camel@jdavis
Whole thread Raw
In response to Obstacles to user-defined range canonicalization functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Mikko Tiihonen
Date:
Subject: Re: [JDBC] Optimize postgres protocol for fixed size arrays
Next
From: Tom Lane
Date:
Subject: Better implementation of CREATE TABLE AS ... WITH NO DATA