## Re: Range Types and length function

From: Florian Pflug Jeff Davis pgsql-hackers(at)postgresql(dot)org Re: Range Types and length function 2011-06-26 22:37:03 43C806C5-492C-4D0A-89B2-A6A4EC47F85C@phlo.org (view raw or whole thread) 2011-06-26 07:18:52 from Jeff Davis  2011-06-26 12:45:20 from Greg Stark   2011-06-26 17:12:07 from Jeff Davis  2011-06-26 22:37:03 from Florian Pflug   2011-06-27 01:12:07 from Jeff Davis    2011-06-27 10:25:24 from Florian Pflug     2011-06-27 16:37:13 from Jeff Davis pgsql-hackers
On Jun26, 2011, at 09:18 , Jeff Davis wrote:
> Currently, there is no way to define a generic "length" function over
> range types, which would give you the distance between the boundary
> points.

I actually wouldn't expect there to be one. From what I gathered
during the last discussion, the ideal behind range types is that they
model sets of the form {x in T | a <= x < b} for arbitrary types
T, with the only requirement being that T be ordered. To compute
a length, you additionally need either an algebraic structure on
T which defines an operation "minus", or some metric which defines
distance(a,b). Both are *much* stronger concepts than simply being
ordered. The problems you outline below seem to me to all root in
this discrepancy.

Strings are a nice example of an ordered type on which no "intuitive"
definition of either "s1 - s2" or "distance(s1,s2)" exists.

> I suppose the "right" way to solve these problems would be:
>
> 1. Force users to supply the "minus" function.
>
> 2. Force users to supply the "zero" value as a constant of the same type
> as the minus function's return value.
>
> 3. Check to see if the minus function's return type is different from
> the subtype. If so, automatically create a new entry in the catalog for
> the "length" function.
>
> I suppose it's not out of the question to do all of that work, but it
> seems like a little much just to get the generic length() function.

That sounds like a poor man's version of type interfaces - i.e. of
a general-purpose way of having various algebraic structures defined
on a type. Having real type interface would be cool, but I don't think
that ranges should introduce a simplistic version of them.

> I don't mind leaving it as-is, and I think it's a fairly reasonable
> solution. But I thought I would re-open it for discussion in case
> someone has a better idea.

I suggest to simply provide no length() function at all. It's beyond
the realm of the mental model behind range types, and providing some
ad-hoc definition is IMHO bound to create more confusion than it'll
help. Especially since "upper(range) - lower(range)" isn't that much
longer to write than "length(range)" anyway.

> The length() function is obviously an
> important function to provide.

I'd say it isn't, but maybe I'm missing some use-case that you have
in mind.

best regards,
Florian Pflug

### pgsql-hackers by date

 Next: From: Florian Pflug Date: 2011-06-26 22:45:02 Subject: Re: Another issue with invalid XML values Previous: From: Peter Eisentraut Date: 2011-06-26 22:24:40 Subject: Re: pg_upgrade defaulting to port 25432