Skip site navigation (1) Skip section navigation (2)

Re: Obstacles to user-defined range canonicalization functions

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Obstacles to user-defined range canonicalization functions
Date: 2011-11-24 19:01:52
Message-ID: 1322161312.16623.11.camel@jdavis (view raw or flat)
Thread:
Lists: 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


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-11-24 19:22:53
Subject: Better implementation of CREATE TABLE AS ... WITH NO DATA
Previous:From: Mikko TiihonenDate: 2011-11-24 18:54:43
Subject: Re: [JDBC] Optimize postgres protocol for fixed size arrays

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group