hstores in pl/python

Hello

this is little bit offtopic, sorry.

I am thinking, so we need a standard associative array support in core
- like Perl, Python or Javascript. So, I don't think, so migration of
hstore to core is good idea.

Regards

Pavel Stehule

2010/12/13 Jan Urbański <wulczer@wulczer.org>:

Hey Pavel,

2010/12/13 Pavel Stehule <pavel.stehule@gmail.com>

Hello

this is little bit offtopic, sorry.

I am thinking, so we need a standard associative array support in core
- like Perl, Python or Javascript. So, I don't think, so migration of
hstore to core is good idea.

Could you tell why in-core associative array support would be better
than in-core hstore support ?
We enjoying to use hstore and thinking that it is implemented great.

Regards

Pavel Stehule

2010/12/13 Jan Urbański <wulczer@wulczer.org>:

It would be cool to be able to transparently use hstores as Python
dictionaries and vice versa. It would be easy enough with hstore as a
core type, but with hstore as an addon it's not that easy.

There was talk about including hstore in core, is there still chance for
that to happen in 9.1? I'd like to include hstore<->dict handling, but
with hstore out-of-core the only half-sane way I see is:
* hack PL/Python's makefile to add -Icontrib/hstore (yuck!)
* create an extension module for Python that knows how to handle
hstores that would live next to plpython.so
* install it in $libdir on make install
* when PL/Python receives or is asked to create an hstore, load the
extension module and use it to parse the value (ugly, probably slow)
* the module would also have to make sure hstore.so is loaded in the
database, which in itself is not pretty, as it would refer to
hstore_in/out symbols

I wrote a module that can be used with current PL/Python to simplify
hstore handling (https://github.com/wulczer/pyhstore), but it suffers
from most of the aforementioned problems, and on top of that you get
hstore->text->dict instead of just hstore->dict, which sucks.

Cheers,
Jan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
// Dmitriy.

2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:

Hey Pavel,

2010/12/13 Pavel Stehule <pavel.stehule@gmail.com>

Hello

this is little bit offtopic, sorry.

I am thinking, so we need a standard associative array support in core
- like Perl, Python or Javascript. So, I don't think, so migration of
hstore to core is good idea.

Could you tell why in-core associative array support would be better
than in-core hstore support ?
We enjoying to use hstore and thinking that it is implemented great.

Because hstore is PostgreSQL specific type. More well known syntax is
better. More - who know, what is hstore? But everybody know, what is
associative array or hash.

Pavel

On Monday 13 December 2010 15:27:48 Pavel Stehule wrote:

2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:

Hey Pavel,

2010/12/13 Pavel Stehule <pavel.stehule@gmail.com>

Hello

this is little bit offtopic, sorry.

I am thinking, so we need a standard associative array support in core
- like Perl, Python or Javascript. So, I don't think, so migration of
hstore to core is good idea.

Could you tell why in-core associative array support would be better
than in-core hstore support ?
We enjoying to use hstore and thinking that it is implemented great.

Because hstore is PostgreSQL specific type. More well known syntax is
better. More - who know, what is hstore? But everybody know, what is
associative array or hash.

So youre disturbed by the name?

Andres

Interesting argument.
I can ask, how many people knows what is tsvector or tsquery ?
Or how many people knows what is polygon or path ?
The answer is: everyone who need or using it.

Hstore is a proven and well designed solution. And in fact I am
surprising why it does not in core yet?!

2010/12/13 Pavel Stehule <pavel.stehule@gmail.com>

2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:

Hey Pavel,

2010/12/13 Pavel Stehule <pavel.stehule@gmail.com>

Hello

this is little bit offtopic, sorry.

I am thinking, so we need a standard associative array support in core
- like Perl, Python or Javascript. So, I don't think, so migration of
hstore to core is good idea.

Could you tell why in-core associative array support would be better
than in-core hstore support ?
We enjoying to use hstore and thinking that it is implemented great.

Because hstore is PostgreSQL specific type. More well known syntax is
better. More - who know, what is hstore? But everybody know, what is
associative array or hash.

Pavel

Regards

Pavel Stehule

2010/12/13 Jan Urbański <wulczer@wulczer.org>:

It would be cool to be able to transparently use hstores as Python
dictionaries and vice versa. It would be easy enough with hstore as a
core type, but with hstore as an addon it's not that easy.

There was talk about including hstore in core, is there still chance

for

that to happen in 9.1? I'd like to include hstore<->dict handling, but
with hstore out-of-core the only half-sane way I see is:
* hack PL/Python's makefile to add -Icontrib/hstore (yuck!)
* create an extension module for Python that knows how to handle
hstores that would live next to plpython.so
* install it in $libdir on make install
* when PL/Python receives or is asked to create an hstore, load the
extension module and use it to parse the value (ugly, probably slow)
* the module would also have to make sure hstore.so is loaded in the
database, which in itself is not pretty, as it would refer to
hstore_in/out symbols

I wrote a module that can be used with current PL/Python to simplify
hstore handling (https://github.com/wulczer/pyhstore), but it suffers
from most of the aforementioned problems, and on top of that you get
hstore->text->dict instead of just hstore->dict, which sucks.

Cheers,
Jan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
// Dmitriy.

--
// Dmitriy.

2010/12/13 Andres Freund <andres@anarazel.de>:

On Monday 13 December 2010 15:27:48 Pavel Stehule wrote:

2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:

Hey Pavel,

2010/12/13 Pavel Stehule <pavel.stehule@gmail.com>

Hello

this is little bit offtopic, sorry.

I am thinking, so we need a standard associative array support in core
- like Perl, Python or Javascript. So, I don't think, so migration of
hstore to core is good idea.

Could you tell why in-core associative array support would be better
than in-core hstore support ?
We enjoying to use hstore and thinking that it is implemented great.

Because hstore is PostgreSQL specific type. More well known syntax is
better. More - who know, what is hstore? But everybody know, what is
associative array or hash.

So youre disturbed by the name?

name and interface - hstore is designed as external module - a
internal class can be designed different.

Pavel

2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:

Interesting argument.

I can ask, how many people knows what is tsvector or tsquery ?
Or how many people knows what is polygon or path ?

TSearch isn't good example. There are not a common interface for fulltext.

The answer is: everyone who need or using it.

Hstore is a proven and well designed solution. And in fact I am
surprising why it does not in core yet?!

Hstore is designed as external module. I am think, so when we can
modify parser when some functionality is internal, then a
implementation can be more effective and without some surprising for
user.

Pavel

On Monday 13 December 2010 16:01:35 Pavel Stehule wrote:

2010/12/13 Andres Freund <andres@anarazel.de>:

On Monday 13 December 2010 15:27:48 Pavel Stehule wrote:

2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:

Hey Pavel,

2010/12/13 Pavel Stehule <pavel.stehule@gmail.com>

Hello

this is little bit offtopic, sorry.

I am thinking, so we need a standard associative array support in
core - like Perl, Python or Javascript. So, I don't think, so
migration of hstore to core is good idea.

Could you tell why in-core associative array support would be better
than in-core hstore support ?
We enjoying to use hstore and thinking that it is implemented great.

Because hstore is PostgreSQL specific type. More well known syntax is
better. More - who know, what is hstore? But everybody know, what is
associative array or hash.

So youre disturbed by the name?

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.

Andres

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'];

or with constructor

somevar = ARRAY[key1 => value1, key2 => value2, .. ]

or some similar.

Regards

Pavel Stehule

Pavel Stehule <pavel.stehule@gmail.com> writes:

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'];

or with constructor

somevar = ARRAY[key1 => value1, key2 => value2, .. ]

or some similar.

We don't normally invent specialized syntax for a specific datatype.
Not even if it's in core.

regards, tom lane

My most serious pro about hstore in core is a better dump/restore
support. Also, since we have so much better hstore and people started
to use it in their projects, it'd be great to have built-in feature in
PostgreSQL, which mimic key-value or document-oriented database.

Oleg

On Mon, 13 Dec 2010, Jan Urbaski wrote:

It would be cool to be able to transparently use hstores as Python
dictionaries and vice versa. It would be easy enough with hstore as a
core type, but with hstore as an addon it's not that easy.

There was talk about including hstore in core, is there still chance for
that to happen in 9.1? I'd like to include hstore<->dict handling, but
with hstore out-of-core the only half-sane way I see is:
* hack PL/Python's makefile to add -Icontrib/hstore (yuck!)
* create an extension module for Python that knows how to handle
hstores that would live next to plpython.so
* install it in $libdir on make install
* when PL/Python receives or is asked to create an hstore, load the
extension module and use it to parse the value (ugly, probably slow)
* the module would also have to make sure hstore.so is loaded in the
database, which in itself is not pretty, as it would refer to
hstore_in/out symbols

I wrote a module that can be used with current PL/Python to simplify
hstore handling (https://github.com/wulczer/pyhstore), but it suffers
from most of the aforementioned problems, and on top of that you get
hstore->text->dict instead of just hstore->dict, which sucks.

Cheers,
Jan

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

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 [] ?

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.
But, Pavel, I feel you idea. You want to make the syntax
clear in particular...

or with constructor

somevar = ARRAY[key1 => value1, key2 => value2, .. ]

or some similar.

Regards

Pavel Stehule

--
// Dmitriy.

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.

Regards

Pavel Stehule

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.

2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:

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 ?

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

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.

Regards

Pavel Stehule

On Dec 13, 2010, at 8:06 AM, Oleg Bartunov wrote:

My most serious pro about hstore in core is a better dump/restore
support. Also, since we have so much better hstore and people started
to use it in their projects, it'd be great to have built-in feature in PostgreSQL, which mimic key-value or document-oriented database.

I thought the JSON data type was supposed to cover this. hstore would remain in contrib.

Davd

2010/12/13 Pavel Stehule <pavel.stehule@gmail.com>

2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:

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 ?

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.

2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:

2010/12/13 Pavel Stehule <pavel.stehule@gmail.com>

2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:

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 ?

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 ?

No I can't. Please, don't understand to me wrong. Usually I am not
against to enhancing a core features. Just I see a significant risk,
so PostgreSQL will not have a associative arrays ever, so I am talking
about it. If I remember well, then in core are very old types from
academic era and types that are necessary for ansi sql conformance.
All others are controversial - there was a big war about XML, there is
still very unsure JSON. TSearch2 is very specific. Very handy type
like "citext" isn't in core. Significant argument for implementation a
type in core is request on parser support.

This is analogy to intarray contrib module. It's same. I am sure, so
you don't want to use a arrays as was implemented in intarray module.

2010/12/14 Pavel Stehule <pavel.stehule@gmail.com>

2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:

2010/12/13 Pavel Stehule <pavel.stehule@gmail.com>

2010/12/13 Dmitriy Igrishin <dmitigr@gmail.com>:

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 ?

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 ?

No I can't. Please, don't understand to me wrong. Usually I am not
against to enhancing a core features. Just I see a significant risk,
so PostgreSQL will not have a associative arrays ever, so I am talking
about it. If I remember well, then in core are very old types from
academic era and types that are necessary for ansi sql conformance.
All others are controversial - there was a big war about XML, there is
still very unsure JSON. TSearch2 is very specific. Very handy type
like "citext" isn't in core. Significant argument for implementation a
type in core is request on parser support.

I believe that truth is born in the debate and I understand you.
Restraint of developers and careful considering of each idea before its
acceptance does PostgreSQL outstanding. Thanks you, hackers !
I want you understand me too. I considering hstore as a data type.
It neither an array nor a map. Yes, it was created to store semi-
structured data in key => value pairs. But it is a type. Hence,
PostgreSQL allows to create array of hstore -- hstore[].
As I mentioned above, assoc. array (map) is a generalization of array.
So, I would not mess map (array) with hstore (data type). In fact,
if PostgreSQL will have a support for maps it should allow to create a
map hstore, i.e. pairs of <TYPE> (key) => hstore (value).
Obviously that map support should be in core if we speak about
generalization of arrays. And even if hstore remain as contrib it
should be possible to create mentioned map of hstores as well as
array of hstores, because, again, hstore is a type by definition.
I like the idea with maps in PostgreSQL if it will be truly
generalization of existing arrays. It would be great!
Responding to you question about why hstore should be in core,
summary:
1. Because it proven, well designed, stable, complete;
2. Because there are many users of hstore;
3. As mentioned by Oleg Bartunov it brings better dump/restore
support.

This is analogy to intarray contrib module. It's same. I am sure, so

you don't want to use a arrays as was implemented in intarray module.

Agree. Furthermore, when we first learned about hstore we are scared
that it is a contib module (considering by us as a third party, not proven
solution) rather than a built-in type. But after some experience we
found it very powerful, useful and stable. It is truly useful data type.
This is yet another argument why I want to see hstore as a built-in type.

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.

--
// Dmitriy.