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

>
> Regards
>
> Pavel Stehule
>
> >
> >>
> >> or with constructor
> >>
> >> somevar = ARRAY[key1 => value1, key2 => value2, .. ]
> >>
> >> or some similar.
> >>
> >> Regards
> >>
> >> Pavel Stehule
> >
> >
> >
> > --
> > // Dmitriy.
> >
> >
> >
>

--
// Dmitriy.