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