Re: hstores in pl/python

Поиск
Список
Период
Сортировка
От Dmitriy Igrishin
Тема Re: hstores in pl/python
Дата
Msg-id AANLkTin+E+kbhWNhzONkxV9QRSE7dKWTx5aMfRh1KY6x@mail.gmail.com
обсуждение исходный текст
Ответ на Re: hstores in pl/python  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: hstores in pl/python  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
Следующее
От: Robert Haas
Дата:
Сообщение: Re: unlogged tables