Re: hstores in pl/python

2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:
>
>
> 2010/12/14 Pavel Stehule <pavel.stehule@gmail.com>
>>
>> 2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:
>> >
>> >
>> > 2010/12/13 Pavel Stehule <pavel.stehule@gmail.com>
>> >>
>> >> 2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:
>> >> >
>> >> >
>> >> > 2010/12/13 Pavel Stehule <pavel.stehule@gmail.com>
>> >> >>
>> >> >> 2010/12/13 Dmitriy Igrishin <dmitigr@gmail.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.stehule@gmail.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.
>
> I believe that truth is born in the debate and I understand you.
> Restraint of developers and careful considering of each idea before its
> acceptance does PostgreSQL outstanding. Thanks you, hackers !
> I want you understand me too. I considering hstore as a data type.
> It neither an array nor a map. Yes, it was created to store semi-
> structured data in key => value pairs. But it is a type. Hence,
> PostgreSQL allows to create array of hstore -- hstore[].
> As I mentioned above, assoc. array (map) is a generalization of array.
> So, I would not mess map (array) with hstore (data type). In fact,
> if PostgreSQL will have a support for maps it should allow to create a
> map hstore, i.e. pairs of <TYPE> (key) => hstore (value).
> Obviously that map support should be in core if we speak about
> generalization of arrays. And even if hstore remain as contrib it
> should be possible to create mentioned map of hstores as well as
> array of hstores, because, again, hstore is a type by definition.
> I like the idea with maps in PostgreSQL if it will be truly
> generalization of existing arrays. It would be great!
> Responding to you question about why hstore should be in core,
> summary:
> 1. Because it proven, well designed, stable, complete;
> 2. Because there are many users of hstore;
> 3. As mentioned by Oleg Bartunov it brings better dump/restore
>     support.

only point 3 is argument for moving to core. And I am not sure. I can
speak, why not "citext" ?

>
>> 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.
>
> Agree. Furthermore, when we first learned about hstore we are scared
> that it is a contib module (considering by us as a third party, not proven
> solution) rather than a built-in type. But after some experience we
> found it very powerful, useful and stable. It is truly useful data type.
> This is yet another argument why I want to see hstore as a built-in type.
>>

what will be changed for you, when Hstore will be in core?

Pavel


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