hstore - Implementation and performance issues around its operators

Hi,

We did a benchmark comparing a Key-Value-Pairs stored as EAV db schema
versus hstore. The results are promising in favor of hstore but there are some
question which remain.

1. Obviously the '@>' has to be used in order to let use the GiST index.
Why is the '->' operator not supported by GiST ('->' is actually
mentioned in all examples of the doc.)?

2. Currently the hstore elements are stored in order as they are
coming from the insert statement / constructor.
Why are the elements not ordered i.e. why is the hstore not cached in
all hstore functions (like hstore_fetchval etc.)?

3. In the source code 'hstore_io.c' one finds the following enigmatic
note: "... very large hstore values can't be output. this could be
fixed, but many other data types probably have the same issue."
What is the max. length of a hstore (i.e. the max. length of the sum
of all elements in text representation)?

4. Last, I don't fully understand the following note in the hstore
doc. (http://www.postgresql.org/docs/current/interactive/hstore.html
):

Notice that the old names are reversed from the convention
formerly followed by the core geometric data types!

Why names? Why not rather 'operators' or 'functions'?
What does this "reversed from the convention" mean concretely?

Yours, Stefan

P.S. I already tried to ask these questions to postgres-performance
and to the hstore authors without success...