Re: obsolete indexing method "rtree"

[Bruce Momjian]

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  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  https://momjian.us
  EnterpriseDB https://enterprisedb.com

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

Re: obsolete indexing method "rtree"

[David G. Johnston]

On Fri, Aug 7, 2020 at 8:46 AM 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  wrote:
>
>>
>> > Why?
>>
>> Because it can hinder the learning process.
>
>
>
> 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.
>
>
> Patch with four additional comments and one modified comment attached.
>
Works for me.

David J.

Re: obsolete indexing method "rtree"

[Jürgen Purtz]

On 06.08.20 10:12, David G. Johnston wrote:
On Thu, Aug 6, 2020 at 12:18 AM Jürgen Purtz > 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


diff --git a/doc/src/sgml/ref/comment.sgml b/doc/src/sgml/ref/comment.sgml
index 965c5a40ad..fd7492a255 100644
--- a/doc/src/sgml/ref/comment.sgml
+++ b/doc/src/sgml/ref/comment.sgml
@@ -306,7 +306,7 @@ COMMENT ON TABLE mytable IS NULL;
Some more examples:
 
 
-COMMENT ON ACCESS METHOD rtree IS 'R-Tree access method';
+COMMENT ON ACCESS METHOD gin IS 'GIN index access method';
 COMMENT ON AGGREGATE my_aggregate (double precision) IS 'Computes sample variance';
 COMMENT ON CAST (text AS int4) IS 'Allow casts from text to int4';
 COMMENT ON COLLATION "fr_CA" IS 'Canadian French';
@@ -316,6 +316,7 @@ COMMENT ON CONSTRAINT bar_col_cons ON bar IS 'Constrains column col';
 COMMENT ON CONSTRAINT dom_col_constr ON DOMAIN dom IS 'Constrains col of domain';
 COMMENT ON DATABASE my_database IS 'Development Database';
 COMMENT ON DOMAIN my_domain IS 'Email Address Domain';
+COMMENT ON EVENT TRIGGER abort_ddl IS 'Aborts all DDL commands';
 COMMENT ON EXTENSION hstore IS 'implements the hstore data type';
 COMMENT ON FOREIGN DATA WRAPPER mywrapper IS 'my foreign data wrapper';
 COMMENT ON FOREIGN TABLE my_foreign_table IS 'Employee Information in other database';
@@ -330,12 +331,15 @@ COMMENT ON OPERATOR CLASS int4ops USING btree IS '4 byte integer operators for b
 COMMENT ON OPERATOR FAMILY integer_ops USING btree IS 'all integer operators for btrees';
 COMMENT ON POLICY my_policy ON mytable IS 'Filter rows by users';
 COMMENT ON PROCEDURE my_proc (integer, integer) IS 'Runs a report';
+COMMENT ON PUBLICATION alltables IS 'Publishes all operations on all tables';
 COMMENT ON ROLE my_role IS 'Administration group for finance tables';
+COMMENT ON ROUTINE my_routine (integer, integer) IS 'Runs a routine (which is a function or procedure)';
 COMMENT ON RULE my_rule ON my_table IS 'Logs updates of employee records';
 COMMENT ON SCHEMA my_schema IS 'Departmental data';
 COMMENT ON SEQUENCE my_sequence IS 'Used to generate primary keys';
 COMMENT ON SERVER myserver IS 'my foreign server';
 COMMENT ON STATISTICS my_statistics IS 'Improves planner row estimations';
+COMMENT ON SUBSCRIPTION alltables IS 'Subscription for all operations on all tables';
 COMMENT ON TABLE my_schema.my_table IS 'Employee Information';
 COMMENT ON TABLESPACE my_tablespace IS 'Tablespace for indexes';
 COMMENT ON TEXT SEARCH CONFIGURATION my_config IS 'Special word filtering';

Re: obsolete indexing method "rtree"

[David G. Johnston]

On Thu, Aug 6, 2020 at 12:18 AM Jürgen Purtz  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.

Re: obsolete indexing method "rtree"

[Jürgen Purtz]

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

Re: obsolete indexing method "rtree"

[Tom Lane]

=?UTF-8?Q?J=c3=bcrgen_Purtz?=  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

obsolete indexing method "rtree"

[Jürgen Purtz]

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