On Fri, Jun 29, 2012 at 6:27 PM, Adrian Klaver <adrian.klaver@gmail.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
happen.
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