Re: hstores in pl/python

2010/12/13 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>

> 2010/12/13 Dmitriy Igrishin <dmitigr(at)gmail(dot)com>:
> >
> >
> > 2010/12/13 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> >>
> >> 2010/12/13 Dmitriy Igrishin <dmitigr(at)gmail(dot)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(dot)stehule(at)gmail(dot)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.