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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
