inclusion of hstore software in main tarball

hi
some time ago i was told on postgresql-general about existence of "hstore"
package for postgresql.
as i understand it is being developed by the same guys that are behind
tsearch2, gin and (at least) recent changes in gist.

would it be possible to include this software in main postgresql tarball? it
would be best if it came as standard feature, but contrib module would also
work.

if you are not familiar with hstore - this is new datatype for postgresql
which allows you to store (and browse and search) any number of pairs of
(key, value) in one field.

i have number of projects coming to my mind which could take advantage of
something like this. the simplest thing is e-commerce site, where all custom
fields (fields dependand on product type) can be stored in one, easily
retrievable, field - thus reducing database load by skipping additional
table scans for custom field table(s).

if you would like to check it: url is:
http://www.sai.msu.su/~megera/postgres/gist/hstore/README.hstore, and the
software itself is downloadable from
http://www.sai.msu.su/~megera/postgres/gist/

best regards

hubert

hubert depesz lubaczewski wrote:

> i have number of projects coming to my mind which could take advantage
> of something like this. the simplest thing is e-commerce site, where all
> custom fields (fields dependand on product type) can be stored in one,
> easily retrievable, field - thus reducing database load by skipping
> additional table scans for custom field table(s).

<slightly_offtopic>
I attended a talk on DB'2 XML Viper stuff the other day. And they were
touting its high performance XML/XQuery support for stuff like this
(their favorite example seems to be meeting appointments). Essentially
they were saying a lot of things simply do not fit a fixed storage
layout, but there are enough similarities between data sets that you can
still benefit from indexing things.

However their stuff also supports nested structures due to their XML
nature. Also due to the XML nature you can optionally check all data
going in to follow an xsd to prevent people from going all too crazy.
</slightly_offtopic>

regards,
Lukas

On Wed, May 03, 2006 at 07:06:09PM +0200, hubert depesz lubaczewski wrote:
> hi
> some time ago i was told on postgresql-general about existence of "hstore"
> package for postgresql.
> as i understand it is being developed by the same guys that are behind
> tsearch2, gin and (at least) recent changes in gist.
>
> would it be possible to include this software in main postgresql tarball? it
> would be best if it came as standard feature, but contrib module would also
> work.

Why put it in contrib unless it depends on being in there? Just grab it
from pgFoundry if you need it.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

On Wednesday 03 May 2006 19:49, Jim C. Nasby wrote:
> On Wed, May 03, 2006 at 07:06:09PM +0200, hubert depesz lubaczewski wrote:
> > hi
> > some time ago i was told on postgresql-general about existence of
> > "hstore" package for postgresql.
> > as i understand it is being developed by the same guys that are behind
> > tsearch2, gin and (at least) recent changes in gist.
> >
> > would it be possible to include this software in main postgresql tarball?
> > it would be best if it came as standard feature, but contrib module would
> > also work.
>
> Why put it in contrib unless it depends on being in there? Just grab it
> from pgFoundry if you need it.
Doesn't this apply to everything in /contrib ? I think hstore is such a small
module that would fit nicely in contrib. For me it really sucks to have all
users of our software download and compile it. Especially when they are used
to just install binary rpms.

If people hate contrib so much why not just get rid of it forever.. Either it
should embrace as much small contrib modules as possible - else it should
disappear in my opinion.

cheers,
Nicolai Petri

Nicolai Petri wrote:

> If people hate contrib so much why not just get rid of it forever.. Either it
> should embrace as much small contrib modules as possible - else it should
> disappear in my opinion.

Actually that's partly the intention. Several contrib modules have been
removed in the recent past, some others have been moved out to
pgFoundry. Some are waiting for a little more maturity before they are
moved into core.

IMHO what you should really be doing is convincing somebody to create
binary packages for your operating system for the interesting/useful
pgFoundry projects.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support