Re: Document "59.2. Built-in Operator Classes" have a clerical error?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: osdba <mailtch(at)163(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Document "59.2. Built-in Operator Classes" have a clerical error?
Date: 2020-08-04 00:01:27
Message-ID: 20200804000127.GJ17519@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Ah, seems Tom has even more detail so we will continue to discuss on
that thread.

---------------------------------------------------------------------------

On Mon, Aug 3, 2020 at 07:51:51PM -0400, Bruce Momjian wrote:
> On Sun, Aug 2, 2020 at 08:43:53PM -0700, David G. Johnston wrote:
> > On Sun, Aug 2, 2020 at 8:17 PM osdba <mailtch(at)163(dot)com> wrote:
> >
> > hi all:
> >
> > In Document "Table 59-1. Built-in GiST Operator Classes":
> >
> > "range_ops any range type && &> &< >> << <@ -|- = @> @>", exist double "@>
> > ",
> >  
> > Should be "<@ @>" ?
> >
> >
> >
> > It helps to reference the current version of the page (or provide a url link)
> > as that section seems to have migrated to Chapter 64 - though it is unchanged
> > even on the main development branch.
> >
> > The table itself is extremely difficult to read: it would be more easily
> > readable if the font was monospaced, but its not.
> >
> > I'm reasonably confident that the equal sign is part of the second-to-last
> > operator while the lone @> is the final operator.  Mostly I say this because
> > GiST doesn't do straight equality so a lone equal operator isn't valid.
>
> I dug into this. This query I think explains why the duplicate is
> there:
>
> SELECT oprname, oprleft::regtype, oprright::regtype, oprresult::regtype
> FROM pg_am
> JOIN pg_opclass ON opcmethod = pg_am.oid
> JOIN pg_amop ON opcfamily = pg_amop.amopfamily
> JOIN pg_operator ON amopopr = pg_operator.oid
> WHERE amname = 'gist'
> AND opcname = 'range_ops'
> ORDER BY 1
>
> oprname | oprleft | oprright | oprresult
> ---------+----------+------------+-----------
> && | anyrange | anyrange | boolean
> &< | anyrange | anyrange | boolean
> &> | anyrange | anyrange | boolean
> -|- | anyrange | anyrange | boolean
> << | anyrange | anyrange | boolean
> <@ | anyrange | anyrange | boolean
> = | anyrange | anyrange | boolean
> >> | anyrange | anyrange | boolean
> --> @> | anyrange | anyrange | boolean
> --> @> | anyrange | anyelement | boolean
>
> Notice that @> appears twice. (I am not sure why @> appears twice in
> the SQL output, while <@ appears only once.) The PG docs explain the
> duplicate:
>
> https://www.postgresql.org/docs/12/functions-range.html
>
> @> contains range int4range(2,4) @> int4range(2,3) t
> @> contains element '[2011-01-01,2011-03-01)'::tsrange @> '2011-01-10'::timestamp t
> <@ range is contained by int4range(2,4) <@ int4range(1,7) t
> <@ element is contained by 42 <@ int4range(1,7) f
>
> There is an anyrange/anyrange version, and an anyrange/anyelement
> version of @> and <@. Anyway, for the docs, I think we can either
> remove the duplicate entry, or modify it to clarify one is for
> anyrange/anyrange and another is for anyrange/anyelement. I suggest the
> first option.
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
> EnterpriseDB https://enterprisedb.com
>
> The usefulness of a cup is in its emptiness, Bruce Lee
>
>
>

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2020-08-04 00:04:28 Re: EDB builds Postgres 13 with an obsolete ICU version
Previous Message Bruce Momjian 2020-08-03 23:51:51 Re: Document "59.2. Built-in Operator Classes" have a clerical error?