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. Regards Pavel Stehule > >> >> or with constructor >> >> somevar = ARRAY[key1 => value1, key2 => value2, .. ] >> >> or some similar. >> >> Regards >> >> Pavel Stehule > > > > -- > // Dmitriy. > > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers