On Sep 18, 2012, at 12:07 PM, Daniele Varrazzo wrote:
> On Tue, Sep 18, 2012 at 5:57 PM, Jonathan S. Katz
> <jonathan.katz@excoventures.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-inPython 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
ofnumbers. This works well for small data sets but if your range type in the DB is something like [1, 10000000] we
couldhave 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
wouldlike to have a base class that would handle the range mechanics that could then be inherited, thus mimicking how
rangetypes 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
sakeof 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
thoughtswhere 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
ownrange class.
Jonathan