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. 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. >> >> 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. > > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
