Re: Range Type Support

On Sep 18, 2012, at 1:08 PM, Daniele Varrazzo wrote:

>> Good point, my mistake in terminology. I was thinking of the "range" function for integers, but that outputs an array of numbers. This works well for small data sets but if your range type in the DB is something like [1, 10000000] we could have a bad day.
>
> You are being misled by the common "range" term. In Python, a range is
> an object primarily made to be iterated, in Postgres is primarily for
> membership/intersection test. A python range (in python 2 xrange()
> would do, in python 3 there's really a range type) is only equivalent
> to a postgres int range with left bound included. OTOH there is no
> step in postgres range. They are definitely two different beasts.

Thanks for the clarification!

>> I would like to propose having a special class to handle the ranges with the same semantics of the Postgres ranges. I would like to have a base class that would handle the range mechanics that could then be inherited, thus mimicking how range types can be extended. Additionally, this would allow us to support continuous ranges (e.g. time, numeric/float/decimal).
>
> Yes, that would be the thing to adapt to. I don't know how much it
> would be useful in Python but I see no more useful thing to adapt to.

I can tell you I have real world uses for it at the app level :-)

>> My concern is I don't want to deviate too far from the standard way of doing things in Python (lists as ranges) for the sake of other libs (i.e. ORMs) interfacing with psycopg2, so I can make strong arguments on both sides.
>
> I don't see any standard python object to adapt to without leaving
> half of the model away.
>
>
> Ah, postgres ranges can also be open left/right/both. So I'd have:
>
> - Basic class with all attributes and implementation, and subclasses
> specifying a type as you mentioned.
>
> - The basic class should have the following attributes, which are a
> direct mapping to the postgres ones and are required to inspect the
> object:
> - lower/upper attributes
> - lower_inc/upper_inc attributes
> - lower_inf/upper_inf attributes
> - isempty attibute

All of the above is good.

> - Possibly it should support an "in" operator and an & operator. But
> then, should we mimic all the operators?
> <http://www.postgresql.org/docs/9.2/static/functions-range.html>
> Probably not.

By "&" do you mean "&&"? Part of me thinks we should support overlaps, but part of the power of the range types feature is that Postgres can handle overlap operations (which are nontrivial to build). I see "in" being used a lot.

> - Parsing interval should resort to the base type parser, so when
> constructing a concrete range type a typecaster should be probably
> specified.
>
> - If a new range type is created in postgres, it would be nice to have
> something like register_range() to introspect pg_range and use the
> right typecaster (rngsubtype) for parsing.

Well, it is really easy to create new ranges in Postgres as is. For example with one line of SQL you can have an INET range. I'm not quite sure I understand what you are suggesting to help with this issue (perhaps I need to dive more into psycopg2 internals?). Perhaps by having the base class available, people using the adapter can write their own extensions.

> - test and docs

Absolutely!

> Having the range iterable seems tempting but the Postgres model
> doesn't have it (even for discrete ranges, it mandates a
> canonicalization function, not a step delta) so the two types wouldn't
> map automatically (not possible to introspect the catalog to get such
> a step)

Perhaps we can put iteration on the onus of the user. I know that with dates, for instance, quite often I will need to iterate over them.

Thoughts?

Jonathan