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

Re: Change in datetime type casting

From: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
To: Adrian Klaver <adrian(dot)klaver(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 21:36:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: psycopg
On Fri, Jun 29, 2012 at 6:27 PM, Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> wrote:
> On 06/29/2012 08:53 AM, Daniele Varrazzo wrote:

>> 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=> INSERT INTO bool_test VALUES (34,'True');
> INSERT 0 1

You are only thinking about half of the story: writing stuff in. I am
thinking about the people who will have to read things out. Writing
"True" as a boolean, not only you are giving people the problem of
knowing the type, you are also adding an entirely different
representation of a boolean into the database that any wannabe user of
that hstore value will have to know. Which is good as any other (but
less good than the only *output* postgres provides), and binds us,
hands and feet, to maintain that one.

It may eventually happen in the future that we will allow any type
into an hstore, but that their conversion will be str() will just not

But then, what about the keys? Shall we convert them too or not? If
so, what about the dict {1: 'hello', '1': 'world'}: how do you convert
it into an hstore?

-- Daniele

In response to


psycopg by date

Next:From: Adrian KlaverDate: 2012-06-30 00:02:09
Subject: Re: Change in datetime type casting
Previous:From: Adrian KlaverDate: 2012-06-29 17:27:05
Subject: Re: Change in datetime type casting

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