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