From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Obstacles to user-defined range canonicalization functions |
Date: | 2011-11-24 03:49:42 |
Message-ID: | 30EF645F-F3EB-4349-997E-F9B0E3FFC909@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Nov24, 2011, at 04:33 , Tom Lane wrote:
> 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.
We could also make the canonicalization function receive the boundaries
and boundary types as separate arguments, and return them in the same way.
In plpgsql the signature could be
canonicalize(inout lower base_type, inout upper base_type,
inout lower_inclusive boolean, inout upper_inclusive boolean)
Not exactly pretty, but it avoids the need for a second continuous range
type...
best regards,
Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2011-11-24 04:07:18 | Re: Obstacles to user-defined range canonicalization functions |
Previous Message | Tom Lane | 2011-11-24 03:33:19 | Obstacles to user-defined range canonicalization functions |