Re: hstores in pl/python

2010/12/13 Dmitriy Igrishin <dmitigr(at)gmail(dot)com>:
>
>
> 2010/12/13 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
>>
>> 2010/12/13 Dmitriy Igrishin <dmitigr(at)gmail(dot)com>:
>> > There are a lot of operators and functions to work with hstore.
>> > Does it worth it to implement similar things only to make it
>> > possible using operator [] ?
>>
>> yes
>>
>> >
>> > 2010/12/13 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
>> >>
>> >> >>
>> >> >> name and interface - hstore is designed as external module - a
>> >> >> internal class can be designed different.
>> >> > Could you actually name such a difference rather than pointing to
>> >> > some
>> >> > airily
>> >> > hint of one? That would make it way much easier to see where you want
>> >> > to
>> >> > go.
>> >>
>> >> My idea is:
>> >>
>> >> somevar['key'] = value
>> >> value = somevar['key'];
>> >
>> > What type of <value> is? Can it be assoc. array ?
>> > Is it possible to indexing assoc. array by position ?
>> > Any many many other questions can be there. So,
>> > I don't think that assoc. arrays has common interface.
>> > Its still specialized type.
>>
>> It's question. Minimally it can be a any known (defined) type -
>> composite type too. It would be nice if we can store data in native
>> format with constraints. Now Hstore can store only text - (note: It's
>> terrible hard to write this as external module, so Hstore does maximum
>> what is possible).
>>
>> > But, Pavel, I feel you idea. You want to make the syntax
>> > clear in particular...
>>
>> I like a possibility to define own types in pg. But sometimes, and
>> associative arrays is it, created interface is "too specific" - like
>> Hstore is it. PostgreSQL doesn't allow to extend a parser - and Hstore
>> respects it in design. So when we could to move hstore functionality
>> to core, we can extend a parser, and we can create some general usable
>> API. It can be big plus for stored procedures programming. This is
>> just my opinion - when Hstore will be in core, then we will not have a
>> native associative array ever, so from my perspective is better Hstore
>> as contrib module.
>
> In my opinion, hstore is defined and implemented well. Its complete in most
> cases. Therefore hstore is mature enough to be in core.
>
> On the other hand associative arrays should be implemented from scratch.
> Very well. Let it be. But how integration hstore in core today can interfere
> with implementation of support for associative arrays in future ? Is it will
> a big problem ?

I think so it can be a problem. Any second implemented feature will
have a handicap, because there will be a similar and realised feature.
Maybe I am too pessimist, but there are very minimal probability to
common existence two similar features in core like hstore or
associative arrays. And because associative arrays are more general
than hstore, I prefer a associative arrays. Hstore works well and a
moving it to core doesn't carry a new value. It's not comparable with
TSearch2. What I know, contrib modules are not problem for DBA now and
Hstore hasn't a "complex" installation like TSearch2 had. More - there
are not a security issues that had to be solved with TSearch2.

Why we need a Hstore in core? Why Hstore need be in core?

Back to plpython. There is possibility to call a external library
without linking. So Hstore must not be in core - and PL/Python can
call it.

Regards

Pavel Stehule

>>
>> Regards
>>
>> Pavel Stehule
>>
>> >
>> >>
>> >> or with constructor
>> >>
>> >> somevar = ARRAY[key1 => value1, key2 => value2, .. ]
>> >>
>> >> or some similar.
>> >>
>> >> Regards
>> >>
>> >> Pavel Stehule
>> >
>> >
>> >
>> > --
>> > // Dmitriy.
>> >
>> >
>> >
>
>
>
> --
> // Dmitriy.
>
>
>