From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Dmitriy Igrishin <dmitigr(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Jan Urbański <wulczer(at)wulczer(dot)org> |
Subject: | Re: hstores in pl/python |
Date: | 2010-12-13 17:04:23 |
Message-ID: | AANLkTikuGR5GobVJmJfZfTLR=8Eux9UWsgK7VrZ4uiNR@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Regards
Pavel Stehule
>
>>
>> or with constructor
>>
>> somevar = ARRAY[key1 => value1, key2 => value2, .. ]
>>
>> or some similar.
>>
>> Regards
>>
>> Pavel Stehule
>
>
>
> --
> // Dmitriy.
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2010-12-13 17:15:29 | Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED |
Previous Message | Tom Lane | 2010-12-13 17:01:10 | Re: Complier warnings on mingw gcc 4.5.0 |