Skip site navigation (1) Skip section navigation (2)

Re: Change in datetime type casting

From: Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>
To: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
Cc: psycopg(at)postgresql(dot)org
Subject: Re: Change in datetime type casting
Date: 2012-06-29 14:51:44
Message-ID: 4FEDC100.3000909@gmail.com (view raw or flat)
Thread:
Lists: psycopg
On 06/28/2012 07:43 AM, Daniele Varrazzo wrote:
> On Thu, Jun 28, 2012 at 3:11 PM, Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> 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?

> -- Daniele
>


-- 
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com



In response to

Responses

psycopg by date

Next:From: Karsten HilbertDate: 2012-06-29 14:59:16
Subject: Re: Change in datetime type casting
Previous:From: Никитин КонстантинDate: 2012-06-29 06:03:27
Subject: A very strange freeze

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group