Re: Range Type Support

From: "Jonathan S(dot) Katz" <jonathan(dot)katz(at)excoventures(dot)com>
To: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
Cc: psycopg(at)postgresql(dot)org
Subject: Re: Range Type Support
Date: 2012-09-18 17:20:59
Message-ID: 61A40BA3-2D4B-4D23-9E92-F2DA9BA93EB1@excoventures.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: psycopg

On Sep 18, 2012, at 12:07 PM, Daniele Varrazzo wrote:
> On Tue, Sep 18, 2012 at 5:57 PM, Jonathan S. Katz
> <jonathan(dot)katz(at)excoventures(dot)com> wrote:
>> Hi,
>>
>> I am using range types in an application I am writing and am planning on writing some mapping to have support with built-in Python ranges, and some simple extensions for dealing with date ranges. I am going to write this on my own regardless, but is anyone working on this for psycopg2? If not, I would be willing to contribute the code I am working on.
>
> What is a "built-in Python range"? You mean some Python object to be
> written with the same semantics of a postgres range? (subtype,
> handling of boundaries, empty singleton).

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.

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

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 was planning on writing the adapter in Python as I am unfamiliar with writing C code for Python. Are there any thoughts where such an adapter would be placed, e.g. in lib.extras
>
> lib.extras is the current kitchen sink and contains all the extra data
> types. I'm toying with the idea of reorganizing the package submodules
> but this will come later.

More or less what I figured which is why I suggested putting initial code in there, particularly if we are defining our own range class.

Jonathan

In response to

Responses

Browse psycopg by date

  From Date Subject
Next Message Daniele Varrazzo 2012-09-18 18:08:42 Re: Range Type Support
Previous Message Federico Di Gregorio 2012-09-18 17:17:39 Re: Range Type Support