"David E. Wheeler" <david@justatheory.com> writes:
> While you’re in there, Tom, would it make sense to fold in something like [this patch][1] I posted last month to
clarifywhich JSONPath comparison operators can take advantage of a index?
> --- a/doc/src/sgml/json.sgml
> +++ b/doc/src/sgml/json.sgml
> @@ -513,7 +513,7 @@ SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @@ '$.tags[*] == "qui"';
> </programlisting>
> For these operators, a GIN index extracts clauses of the form
> <literal><replaceable>accessors_chain</replaceable>
> - = <replaceable>constant</replaceable></literal> out of
> + == <replaceable>constant</replaceable></literal> out of
> the <type>jsonpath</type> pattern, and does the index search based on
> the keys and values mentioned in these clauses. The accessors chain
> may include <literal>.<replaceable>key</replaceable></literal>,
Right, clearly a typo.
> @@ -522,6 +522,9 @@ SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @@ '$.tags[*] == "qui"';
> The <literal>jsonb_ops</literal> operator class also
> supports <literal>.*</literal> and <literal>.**</literal> accessors,
> but the <literal>jsonb_path_ops</literal> operator class does not.
> + Only the <literal>==</literal> and <literal>!=</literal> <link
> + linkend="functions-sqljson-path-operators">SQL/JSON Path Operators</link>
> + can use the index.
> </para>
You sure about that? It would surprise me if we could effectively use
a not-equal condition with an index. If it is only == that works,
then the preceding statement seems sufficient.
regards, tom lane