Re: hstore improvements?

Andrew Gierth wrote:
> I have a patch almost done that adds some obvious but currently
> missing functionality to hstore... 
> If there's any other features that people find notably missing from
> hstore, I could stick them in too; any requests?

Currently hstore gives me an indexed operator to query if
a hstore contains a single key.    It'd be nice if there were
as way to extend this so that I could ask for only records
that have all or any the keys in a query. 'a=>1, b=>1'::hstore ? 'a,b'
In one database I put ids of each of the keys in a
hstore into a largely redundant intarray to be able to
do fast queries for rows containing all the hstore-keys
in a set.

Even cooler might be extending the hstore '?' operator to
allow expressions similar to intarray's queries: 'a=>1, b=>1'::hstore ? 'a|b' 'a=>1, b=>1'::hstore ? 'a&b' 'a=>1,
b=>1'::hstore? 'a&(b|c)'
 
I don't have a need for the more general expressions, but if
the code can be borrowed from intarray to handle both, that'd
be sweet.


I once wanted a variation of hstore where a key could have
multiple values(and the ability to query them). 'a=>x, a=>y'::hstore @> 'a=>x'
I imagine most EAV systems allow multiple values for each
attribute - and a hstore that supported this could probably
be a pretty nice general solution for many EAV systems.  IIRC
other people asked about similar on the lists before.


> Also, hstore has an (undocumented) limit of 65535 bytes for keys and
> values, and it does not behave very cleanly when given longer values
> (it truncates them mod 2^16, rather than erroring). That gives rise to
> two obvious questions: (1) are those lengths reasonable? they strike
> me as being rather long for keys and rather short for values; and (2)
> should exceeding the lengths throw an error?