From: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
---|---|
To: | psycopg(at)postgresql(dot)org |
Subject: | Re: Change in datetime type casting |
Date: | 2012-06-29 15:06:52 |
Message-ID: | 4FEDC48C.6050309@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
On 06/29/2012 07:59 AM, Karsten Hilbert wrote:
> On Fri, Jun 29, 2012 at 07:51:44AM -0700, Adrian Klaver wrote:
>
>>>> Which begs the question why does the adapter not do str(value) when creating
>>>> the ARRAY?
>>>
>>> Because it would give a false promise of working. If I put a date in
>>> my db, I'm expecting a date to come out: any other result is an error.
>>> The hstore adapter is documented to take strings mapping: results with
>>> any other mapping is undefined. A better behaviour could be to
>>> explicitly raise an explicit exception, but it would be less efficient
>>> than trusting the user he is using the adapter as documented (see
>>> HstoreAdapter._getquoted_9(): we adapt the dict.values() list, not
>>> iterate on each values).
>>>
>>> If writing a date in and reading a string out is enough for your
>>> application, you can easily write your own specialized hstore adapter
>>> based on the code in extras.py.
>>
>> The following change in extras.py solves the problem for dates and
>> other non string types.:
>>
>> class HstoreAdapter(object):
>> """Adapt a Python dict to the hstore syntax."""
>> def __init__(self, wrapped):
>> self.wrapped = wrapped
>> for k in self.wrapped: <--
>> self.wrapped[k] = str(self.wrapped[k]) <--
>>
>> Is there a possibility it could find its way into psycopg2 proper?
>
> It would not solve this concern voiced above:
>
>>> Because it would give a false promise of working.
As I said before there is no false promise. hstore is just a fancy
string type. There is no expectation that types will be preserved, so
why maintain the illusion?
>
> Karsten
>
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2012-06-29 15:10:33 | Re: Change in datetime type casting |
Previous Message | Federico Di Gregorio | 2012-06-29 14:59:46 | Re: Change in datetime type casting |