> 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 <[email protected]> >> >> >> >> >> 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 ?
Regards
Pavel Stehule
> >> >> or with constructor >> >> somevar = ARRAY[key1 => value1, key2 => value2, .. ] >> >> or some similar. >> >> Regards >> >> Pavel Stehule > > > > -- > // Dmitriy. > > >
