On Mon, May 11, 2020 at 4:20 PM Bruce Momjian <bruce@momjian.us> wrote:
> Sorry for the delay in replying. Yes, I agree we should list all of
> those operator class cases where we now take arguments. I looked at the
> patch but got confused and missed the doc changes that clearly need to
> be in the release notes. I see these operator classes now taking
> parameters, as you helpfully listed in your commit message:
>
> tsvector_ops
> gist_ltree_ops
> gist__ltree_ops
> gist_trgm_ops
> gist_hstore_ops
> gist__int_ops
> gist__intbig_ops
>
> I assume the double-underscore is because the first underscore is to
> separate words, and the second one is for the array designation, right?
Yes, this is true.
> So my big question is whether people will understand when they are using
> these operator classes, since many of them are defaults. Can you use an
> operator class parameter when you are just using the default operator
> class and not specifying its name?
Actually no. Initial version of patch allowed to explicitly specify
DEFAULT keyword instead of opclass name. But I didn't like idea to
allow keyword instead of name there.
I've tried to implement syntax allowing specifying parameters without
both new keyword and opclass name, but that causes a lot of grammar
problems.
Finally, I've decided to provide parameters functionality only when
specifying opclass name. My motivation is that opclass parameters is
functionality for advanced users, who are deeply concerned into what
opclass do. For this category of users it's natural to know the
opclass name.
> What I thinking that just saying
> the operator class take arguments might not be helpful. I think I see
> enough detail in the documentation to write release note items for
> these, but I will have to point out they need to specify the operator
> class, even if it is the default, right?
My point was that we should specify where to look to find new
functionality. We can don't write opclass names, because those names
might be confusing for users who are not aware of them. We may
briefly say that new parameters are introduced for GiST for tsvector,
contrib/intarray, contrib/pg_trgm, contrib/ltree, contrib/hstore.
What do you think?
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company