Re: hstores in pl/python - Mailing list pgsql-hackers

From Dmitriy Igrishin
Subject Re: hstores in pl/python
Date
Msg-id AANLkTin+E+kbhWNhzONkxV9QRSE7dKWTx5aMfRh1KY6x@mail.gmail.com
Whole thread Raw
In response to Re: hstores in pl/python  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: hstores in pl/python  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers


2010/12/13 Pavel Stehule <pavel.stehule@gmail.com>
2010/12/13 Dmitriy Igrishin <dmitigr@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.stehule@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 ?

Regards

Pavel Stehule

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



--
// Dmitriy.


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
Next
From: Robert Haas
Date:
Subject: Re: unlogged tables