2010/12/14 Pavel Stehule <pavel.steh...@gmail.com> > 2010/12/13 Dmitriy Igrishin <dmit...@gmail.com>: > > > > > > 2010/12/14 Pavel Stehule <pavel.steh...@gmail.com> > >> > >> 2010/12/13 Dmitriy Igrishin <dmit...@gmail.com>: > >> > > >> > > >> > 2010/12/13 Pavel Stehule <pavel.steh...@gmail.com> > >> >> > >> >> 2010/12/13 Dmitriy Igrishin <dmit...@gmail.com>: > >> >> > > >> >> > > >> >> > 2010/12/13 Pavel Stehule <pavel.steh...@gmail.com> > >> >> >> > >> >> >> 2010/12/13 Dmitriy Igrishin <dmit...@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.steh...@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" ? > 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.