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>:
>> >
>> >
>> > 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.
>
> Okay. According to
> http://www.postgresql.org/docs/9.0/static/arrays.html
> PostreSQL array - collection of values of the same type -- built-in or
> user-defined. Assoc. arrays (maps) are generalized arrays by definition.
> So, maps in PostgreSQL should become a generalizations of an currently
> existing arrays.
> Furthermore, if we speak about generalization, map keys must be arbitrary
> typed. And yes, ordering operator must exists for a key type and so on...
> Otherwise it will be specialized type just for fancy operator[] with
> text argument user "friendly", rather than map.
>
>> 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?
>
> Well, okay. Could you explain by what formal criterion types become
> built-in ?

No I can't. Please, don't understand to me wrong. Usually I am not
against to enhancing a core features. Just I see a significant risk,
so PostgreSQL will not have a associative arrays ever, so I am talking
about it. If I remember well, then in core are very old types from
academic era and types that are necessary for ansi sql conformance.
All others are controversial - there was a big war about XML, there is
still very unsure JSON. TSearch2 is very specific. Very handy type
like "citext" isn't in core. Significant argument for implementation a
type in core is request on parser support.

This is analogy to intarray contrib module. It's same. I am sure, so
you don't want to use a arrays as was implemented in intarray module.

>>
>> 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.
>
> BTW. Keys of maps in Python can be differently typed.
>>
>> Regards
>>
>> Pavel Stehule
>>
>>
>> >>
>> >> Regards
>> >>
>> >> Pavel Stehule
>> >>
>> >> >
>> >> >>
>> >> >> or with constructor
>> >> >>
>> >> >> somevar = ARRAY[key1 => value1, key2 => value2, .. ]
>> >> >>
>> >> >> or some similar.
>> >> >>
>> >> >> Regards
>> >> >>
>> >> >> Pavel Stehule
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > // Dmitriy.
>> >> >
>> >> >
>> >> >
>> >
>> >
>> >
>> > --
>> > // Dmitriy.
>> >
>> >
>> >
>
>
>
> --
> // Dmitriy.
>
>
>