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: Federico Di Gregorio <fog(at)dndg(dot)it>, psycopg(at)postgresql(dot)org
Subject: Re: Change in datetime type casting
Date: 2012-06-29 17:27:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: psycopg
On 06/29/2012 08:53 AM, Daniele Varrazzo wrote:
> On Fri, Jun 29, 2012 at 3:59 PM, Federico Di Gregorio <fog(at)dndg(dot)it> wrote:
>> On 29/06/12 16:51, Adrian Klaver wrote:
>>>> 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
>>> and
>>> The following change in 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?
> This changes the dictionary inplace: this is definitely not making its way!
>> Using str() is wrong: at least you should use adapt() and .getquoted()
>> to avoid SQL-injection attacks.
> Agreed: str() is one of the last things I'd like there. First for
> encodings problem: str() or unicode()? Then, str gets you a Python
> string representation of the object: str(True) is "True", in postgres
> it would have been "t".

test=> \d bool_test
     Table "public.bool_test"
   Column  |  Type   | Modifiers
  ifd      | integer |
  bool_fld | boolean |

test=> INSERT INTO bool_test VALUES (34,'True');

test=> SELECT * from bool_test where ifd=34;
  ifd | bool_fld
   34 | t
(1 row)

No problem.

> A better implementation of the idea would have *at least* the postgres
> representation of the types in the database. For this, as noted by
> Adrian, the current ISqlQuote is not right as it contains the quotes,
> including the E where required and possibly the cast. Implementing the
> long due ISQL interface (the one to complement PQexecParams) would
> allow at least correct adaptation (no injection) and return postgres
> format.
>> But I think that adding something like that would be fine. Daniele?
> I've expressed my opinion yesterday: I don't like the idea. I'm pretty
> sure anybody who wants to put non-string stuff into an hstore would
> have his own need and would be not a problem at all to pre-process
> their dict before passing them to the database. Choosing your own
> string representation seems an application choice, not one the driver
> should make, and specifically passing the Python str() seems a bad
> choice. The postgres string representation (such that value::type
> would work, although type is not stored in the hstore and should be
> known by other means) would be something I wouldn't regret.

Once again there is no putting of non string stuff into a hstore field. 
By definition it is string only. If someone wants to maintain type 
consistency, do not use hstore, use a regular field. When you make the 
choice to use an hstore field you have made the choice to ignore types. 
The adapter should respect that. It is up to the user to deal with that 
when the data is returned.

> -- Daniele

Adrian Klaver

In response to


psycopg by date

Next:From: Daniele VarrazzoDate: 2012-06-29 21:36:08
Subject: Re: Change in datetime type casting
Previous:From: Daniele VarrazzoDate: 2012-06-29 15:53:09
Subject: Re: Change in datetime type casting

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