Re: Change in datetime type casting

On 06/29/2012 02:36 PM, Daniele Varrazzo wrote:
> On Fri, Jun 29, 2012 at 6:27 PM, Adrian Klaver <adrian.klaver@gmail.com> wrote:

>
>> 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.

The basic problem is that you are clinging to the notion that types have any
place in hstore. To illustrate:

test=> \d hstore_type
      Table "utility.hstore_type"
                                                            
 Column |       Type        | Modifiers
                                                            
--------+-------------------+-----------
                                                            
 fld_1  | integer           |
                                                            
 fld_2  | character varying |
                                                            
 fld_3  | boolean           |
                                                            
 fld_4  | character varying |

test=> SELECT * from hstore_type ;


 fld_1 | fld_2 | fld_3 | fld_4

-------+-------+-------+-------


     1 | 1     | t     | t


     2 | 2     | f     | f

test=> insert INTO hstore_test(hstore_fld) SELECT hstore(ht) from hstore_type as ht;
INSERT 0 2

test=> SELECT * from hstore_test;
 id |                       hstore_fld
----+--------------------------------------------------------
  4 | "fld_1"=>"1", "fld_2"=>"1", "fld_3"=>"t", "fld_4"=>"t"


  5 | "fld_1"=>"2", "fld_2"=>"2", "fld_3"=>"f", "fld_4"=>"f"


While I like the idea of a hstore type that maintains awareness of the type of its element
values, that does not exist at this time. Trying to get psycopg2 to impose that over
top of what does exist is fruitless. If you forget about maintaining type information the
problem gets a whole lot easier.

>
> 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.

That was a quick and dirty hack for proof of concept. I understand now the dangers in that
approach and can see a more sophisticated method is in order.
>
> 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?

Yes convert keys. Throw an exception when keys convert to same string value.

>
>
> -- Daniele
>


--
Adrian Klaver
adrian.klaver@gmail.com