Re: Range Type Support

On Wed, Sep 19, 2012 at 5:59 PM, Jonathan S. Katz
<jonathan(dot)katz(at)excoventures(dot)com> wrote:
>
> On Sep 18, 2012, at 1:08 PM, Daniele Varrazzo wrote:

>> 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 :-)

Can you post an example of this use? It could be interesting to know
to design the object to adapt to.

>> - 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.

There's no && operator in python. But you are sorta right: I was
thinking about an operator saying if two intervals match, not to
return their intersection. But would it be any useful? It's definitely
little thing compared to the richness of the postgres range type and
implementing all of them is a project on its own. "in" otoh would be
easy to implement.

>> - 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.

Just making my mind about what to do. There's not really the need of a
separate python class for each different range type supported by
postgres: the typecaster for dates range is a generic range typecaster
(one knowing the syntax "[from,to)" and its nuances) plus a reference
to the dates typecaster to ask parsing the "from" and "to" parts. What
changes in the int typecaster is only the sub-typecaster it refers to.
The composite typecaster solves the same type of problem, probably
even a more complex one.

>> 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.

I don't want to add features to the typecaster that then I would have
to maintain before knowing there is a use for them, so for the moment
the object returned would be just a record to retrieve what's in the
database. Of course you can come with a very rich model of a python
range, maybe deserving a pypi project on its own, and have a
typecaster to get these objects from the db, instead of a more basic
one that psycopg would provide.

-- Daniele