Re: hstores in pl/python

2010/12/14 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>

> 2010/12/13 Dmitriy Igrishin <dmitigr(at)gmail(dot)com>:
> >
> >
> > 2010/12/14 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>:
> >> >> >
> >> >> >
> >> >> > 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.
> >
> > 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" ?
>
All of these 3 arguments closely related. Who needs better dump/restore
of hstore? (3) Right -- many users of hstore (2). Why hstore is popular and
has many users? -- Right -- because it proven, well designed, stable and
complete (1).

> >
> >> 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?
>
For me personally ? -- nothing. But I can ask you just the same question.

Again, hstore is a date type, not an associative array. Array - is a
collection
of elements of some data type, e.g. integer, text or hstore.
Thus hstore cannot be considered as an replacement of associative *arrays*.

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

--
// Dmitriy.