subscript of type <type>text</type>
   can be specified; it is interpreted as a key and the corresponding
   value is fetched or stored.  For example,

<programlisting>
CREATE TABLE mytable (h hstore);
INSERT INTO mytable VALUES ('a=>b, c=>d');
SELECT h['a'] FROM mytable;
 h
---
 b
(1 row)

UPDATE mytable SET h['c'] = 'new';
SELECT h FROM mytable;
          h
----------------------
 "a"=>"b", "c"=>"new"
(1 row)
</programlisting>

   A subscripted fetch returns <literal>NULL</literal> if the subscript
   is <literal>NULL</literal> or that key does not exist in
   the <type>hstore</type>.  (Thus, a subscripted fetch is not greatly
   different from the <literal>-&gt;</literal> operator.)
   A subscripted update fails if the subscript is <literal>NULL</literal>;
   otherwise, it replaces the value for that key, adding an entry to
   the <type>hstore</type> if the key does not already exist.
  </para>
 </sect2>

 <sect2 id="hstore-indexes">
  <title>Indexes</title>

  <para>
   <type>hstore</type> has GiST and GIN index support for the <literal>@&gt;</literal>,
   <literal>?</literal>, <literal>?&amp;</literal> and <literal>?|</literal> operators. For example:
  </para>
<programlisting>
CREATE INDEX hidx ON testhstore USING GIST (h);

CREATE INDEX hidx ON testhstore USING GIN (h);
</programlisting>

  <para>
   <literal>gist_hstore_ops</literal> GiST opclass approximates a set of
   key/value pairs as a bitmap signature.  Its optional integer parameter
   <literal>siglen</literal> determines the
   signature length in bytes.  The default length is 16 bytes.
   Valid values of signature length are between 1 and 2024 bytes.  Longer
   signatures lead to a more precise search (scanning a smaller fraction of the index and
   fewer heap pages), at the cost of a larger index.
  </para>

  <para>
   Example of creating such an index with a signature length of 32 bytes:
<programlisting>
CREATE INDEX hidx ON testhstore USING GIST (h gist_hstore_ops(siglen=32));
</programlisting>
  </para>

  <para>
   <type>hstore</type> also supports <type>btree</type> or <type>hash</type> indexes for
   the <literal>=</literal> operator. This allows <type>hstore</type> columns to be
   declared <literal>UNIQUE</literal>, or to be used in <literal>GROUP BY</literal>,
   <literal>ORDER BY</literal> or <literal>DISTINCT</literal> expressions. The sort ordering
   for <type>hstore</type> values is not particularly useful, but these indexes
   may be useful for equivalence lookups. Create indexes for <literal>=</literal>
   comparisons as follows:
  </para>
<programlisting>
CREATE INDEX hidx ON testhstore USING BTREE (h);

CREATE INDEX hidx ON testhstore USING HASH (h);
</programlisting>
 </sect2>

 <sect2 id="hstore-examples">
  <title>Examples</title>

  <para>
   Add a key, or update an existing key with a new value:
<programlisting>
UPDATE tab SET h['c'] = '3';
</programlisting>
   Another way to do the same thing is:
<programlisting>
UPDATE tab SET h = h || hstore('c', '3');
</programlisting>
   If multiple keys are to be added or changed in one operation,
   the concatenation approach is more efficient than subscripting:
<programlisting>
UPDATE tab SET h = h || hstore(array['q', 'w'], array['11', '12']);
</programlisting>
  </para>

  <para>
   Delete a key:
<programlisting>
UPDATE tab SET h = delete(h, 'k1');
</programlisting>
  </para>

  <para>
   Convert a <type>record</type> to an <type>hstore</type>:
<programlisting>
CREATE TABLE test (col1 integer, col2 text, col3 text);
INSERT INTO test VALUES (123, 'foo', 'bar');

SELECT hstore(t) FROM test AS t;
                   hstore
---------------------------------------------
 "col1"=&gt;"123", "col2"=&gt;"foo", "col3"=&gt;"bar"
(1 row)
</programlisting>
  </para>

  <para>
   Convert an <type>hstore</type> to a predefined <type>record</type> type:
<programlisting>
CREATE TABLE test (col1 integer, col2 text,