First pass (incomplete) of "rich" JSONB indexing docs

[freshtonic]

I'm winging it a bit here.

1. I landed on rich_jsonb as the name of the new index type (had to pick something!)
2. I circumvented the bike-shedding naming EQL function equivalents for nameless Postgres operators by making the operator an argument to a generic cs_binop_v1 function:

cs_binop_v1(left_arg, '->', right_arg)

I'm fairly certain this can be made to work in PGPLSQL

[CDThomas]

How would cs_binop_v1 handle the different return types between operators (jsonb, text, or bool)? Can Pl/pgSQL handle multiple return types for a single function?

[freshtonic]

@CDThomas that is a very good question!

Postgres does support limited polymorphism via anyelement, anyarray, anynonarray, anyenum, or anyrange.

The way it works is that if you have a function foo(anyelement) -> anyelement then anyelement becomes the same type everywhere it appears.

So foo(text) -> text would be allowed, but foo(text) -> integer would not.

I think that is sufficient to express all of the variations required by cs_binop_v1 but I will need to double check.

[CDThomas]

How would cs_binop_v1 determine which index to use for a particular operator? For example, if it needed to choose between regular ORE and rich JSON's ORE, how would that work?

Or is cs_binop_v1 only intended to be used with rich JSON? In that case could we add the index name to the func name (something like cs_rich_jsonb_binop_v1)?

[freshtonic]

@CDThomas given that a function can be polymorphic - I think that means cs_binop_v1 will have multiple definitions. So if both left and right args are the encrypted jsonb type, then the ORE index defined for that particular type will be used, for example.

[auxesis]

Closing in lieu of #14.