Обсуждение: obsolete indexing method "rtree"

We removed the indexing method "rtree" in version 8.3 and replaced it with "gist". Until today there are some "rtree" heritages:

• "CREATE INDEX ... USING rtree ..." is valid syntax and leads to the message "NOTICE:  substituting access method gist for obsolete method rtree"
• The documentation refers to the method in ref/comments.sgml and ref/create_index.sgml.
• The documentation uses the term "R-Tree" in gist.sgml, seg.sgml, and xindex.sgml. That's ok because in this cases it refers to the abstract concept of R-trees and not to the eliminated implementation.

Isn't it time to disallow this syntax and remove all references and messages? The situation concerning index types, access methods, operator classes, and index related extensions is complicate enough and hard to explain to newcomers. Every simplification should be welcomed.

--

Jürgen Purtz

=?UTF-8?Q?J=c3=bcrgen_Purtz?= <juergen@purtz.de> writes:
> We removed the indexing method "rtree" in version 8.3 and replaced it 
> with "gist". Until today there are some "rtree" heritages:

>   * "CREATE INDEX ... USING rtree ..." is valid syntax and leads to the
>     message "NOTICE:  substituting access method gist for obsolete
>     method rtree"
>   * The documentation refers to the method in ref/comments.sgml and
>     ref/create_index.sgml.
>   * The documentation uses the term "R-Tree" in gist.sgml, seg.sgml, and
>     xindex.sgml. That's ok because in this cases it refers to the
>     abstract concept of R-trees and not to the eliminated implementation.

> Isn't it time to disallow this syntax and remove all references and 
> messages?

Why?  It's not hurting anything to continue the substitution in CREATE
INDEX.  The example in comments.sgml is just an example, and is not
meant to reflect a built-in object any more than the adjacent examples
are.

Possibly the comment in seg.sgml should be adjusted to refer to GiST
indexes --- but then again, it's not entirely clear whether it's even
still relevant for GiST indexes.  Perhaps it's talking about a deficiency
that was specific to the old rtree code.

            regards, tom lane

> Why?

Because it can hinder the learning process. And it's possible that 
people ignore or forget about the warning message, but are confused 
somewhat later that commands like \d shows GiST instead of RTREE.

> It's not hurting anything to continue the substitution in CREATE
> INDEX.
Yes, it's not hurting. But it makes the life of newcomers a little 
harder. Why not stripping away thinks which aren't used since 12 years?
> Possibly the comment in seg.sgml should be adjusted to refer to GiST
> indexes --- but then again, it's not entirely clear whether it's even
> still relevant for GiST indexes.
This comment is not specific to the old rtree implementation. In 
general, the input to R-Trees and the algorithm which creates the 
'rectangles' in non-leaf nodes influences the building of the tree and 
hereinafter the performance of access methods.
> Perhaps it's talking about a deficiency
> that was specific to the old rtree code.

And sometimes even experts have to spend time thinking about the situation.

Nevertheless, this is a tiny issue. Unfortunately I don't have the 
knowledge to modify the C-source and create a patch.

--

Jürgen Purtz

On Thu, Aug 6, 2020 at 12:18 AM Jürgen Purtz <juergen@purtz.de> wrote:

> Why?

Because it can hinder the learning process.

FWIW I'd at least fixup comment.sgml to reference a current type.  And while in there might as well add missing examples for the following since we seem to have a goal of providing one example for every syntax (operators get two in order to show NONE, rightarg).

  EVENT TRIGGER object_name |
  PUBLICATION object_name |
  SUBSCRIPTION object_name |

  ROUTINE routine_name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] |  

Such a "make current" patch that covers this complaint seems reasonable; IOW, why not if you are in there anyway - rtree has some baggage and no particular merit such that a different label would be worse.

I don't see the value of removing the backward compatibility hack if it's not bothering the developers.  Whether the documentation should be changed to basically only cover this and nothing more I cannot say without studying said documentation.  I agree with the general motive though.

David J.

Patch with four additional comments and one modified comment attached.

--

Jürgen Purtz

On Fri, Aug  7, 2020 at 05:46:45PM +0200, Jürgen Purtz wrote:
> 
> On 06.08.20 10:12, David G. Johnston wrote:
> 
>     On Thu, Aug 6, 2020 at 12:18 AM Jürgen Purtz <juergen@purtz.de> wrote:
> 
> 
>         > Why?
> 
>         Because it can hinder the learning process.
> 
> 
>     FWIW I'd at least fixup comment.sgml to reference a current type.  And
>     while in there might as well add missing examples for the following since
>     we seem to have a goal of providing one example for every syntax (operators
>     get two in order to show NONE, rightarg).
> 
>       EVENT TRIGGER object_name |
>       PUBLICATION object_name |
>       SUBSCRIPTION object_name |
>       ROUTINE routine_name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
>     |  
> 
>     Such a "make current" patch that covers this complaint seems reasonable;
>     IOW, why not if you are in there anyway - rtree has some baggage and no
>     particular merit such that a different label would be worse.
> 
>     I don't see the value of removing the backward compatibility hack if it's
>     not bothering the developers.  Whether the documentation should be changed
>     to basically only cover this and nothing more I cannot say without studying
>     said documentation.  I agree with the general motive though.
> 
>     David J.
> 
> 
> Patch with four additional comments and one modified comment attached.

Thanks, patch applied through 11.  We added ROUTINE/PROCEDURE in PG 11,
so I decided not to cherry pick items to be applied prior to that
release.  Thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

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