Horton

Thread

Commits

  1. Rename the "point is strictly above/below point" comparison operators.

  2. Remove deprecated containment operators for built-in types

  1. Bogus documentation for bogus geometric operators

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-04-21T04:42:40Z

    While revising the docs for the geometric operators, I came across
these entries:

<^	Is below (allows touching)?	circle '((0,0),1)' <^ circle '((0,5),1)'
>^	Is above (allows touching)?	circle '((0,5),1)' >^ circle '((0,0),1)'

These have got more than a few problems:

1. There are no such operators for circles, so the examples are pure
fantasy.

2. What these operators do exist for is points (point_below, point_above
respectively) and boxes (box_below_eq, box_above_eq).  However, the
stated behavior is not what the point functions actually do:

point_below(PG_FUNCTION_ARGS)
...
	PG_RETURN_BOOL(FPlt(pt1->y, pt2->y));

point_above(PG_FUNCTION_ARGS)
...
	PG_RETURN_BOOL(FPgt(pt1->y, pt2->y));

So point_below would be more accurately described as "is strictly below",
so its operator name really ought to be <<|.  And point_above is "is
strictly above", so its operator name ought to be |>>.

3. The box functions do seem to be correctly documented:

box_below_eq(PG_FUNCTION_ARGS)
...
	PG_RETURN_BOOL(FPle(box1->high.y, box2->low.y));

box_above_eq(PG_FUNCTION_ARGS)
...
	PG_RETURN_BOOL(FPge(box1->low.y, box2->high.y));

But there are comments in the source code to the effect of

 * box_below_eq and box_above_eq are obsolete versions that (probably
 * erroneously) accept the equal-boundaries case.  Since these are not
 * in sync with the box_left and box_right code, they are deprecated and
 * not supported in the PG 8.1 rtree operator class extension.

I'm not sure how seriously to take this deprecation comment, but it
is true that box_below (<<|) and box_above (|>>) have analogs for
other data types while these functions don't.

4. Just for extra fun, these point operators are listed in some
GIST and SP-GIST opclasses; though the box ones are not, as per
that code comment.

Perhaps it's too late in the v13 cycle to actually do anything
about this code-wise, but what should I do documentation-wise?
I'm certainly not eager to document that these operators behave
inconsistently depending on which type you're talking about.

			regards, tom lane

  2. Re: Bogus documentation for bogus geometric operators

    Emre Hasegeli <emre@hasegeli.com> — 2020-04-28T16:33:53Z

    > Perhaps it's too late in the v13 cycle to actually do anything
> about this code-wise, but what should I do documentation-wise?
> I'm certainly not eager to document that these operators behave
> inconsistently depending on which type you're talking about.

I don't think we need to worry too much about doing something in the
v13 cycle.  The geometric operators had and evidently still have so
many bugs.  Nobody complains about them other than the developers who
read the code.

I am happy to prepare a patch for the next release to fix the current
operators and add the missing ones.

  3. Re: Bogus documentation for bogus geometric operators

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-04-28T17:33:24Z

    Emre Hasegeli <emre@hasegeli.com> writes:
>> Perhaps it's too late in the v13 cycle to actually do anything
>> about this code-wise, but what should I do documentation-wise?
>> I'm certainly not eager to document that these operators behave
>> inconsistently depending on which type you're talking about.

> I don't think we need to worry too much about doing something in the
> v13 cycle.  The geometric operators had and evidently still have so
> many bugs.  Nobody complains about them other than the developers who
> read the code.

Yeah, I ended up just documenting the current state of affairs.

> I am happy to prepare a patch for the next release to fix the current
> operators and add the missing ones.

Sounds great!

			regards, tom lane

  4. Re: Bogus documentation for bogus geometric operators

    Emre Hasegeli <emre@hasegeli.com> — 2020-08-21T11:00:45Z

    > While revising the docs for the geometric operators, I came across
> these entries:
>
> <^      Is below (allows touching)?     circle '((0,0),1)' <^ circle '((0,5),1)'
> >^      Is above (allows touching)?     circle '((0,5),1)' >^ circle '((0,0),1)'
>
> These have got more than a few problems:
>
> 1. There are no such operators for circles, so the examples are pure
> fantasy.
>
> 2. What these operators do exist for is points (point_below, point_above
> respectively) and boxes (box_below_eq, box_above_eq).  However, the
> stated behavior is not what the point functions actually do:
>
> point_below(PG_FUNCTION_ARGS)
> ...
>         PG_RETURN_BOOL(FPlt(pt1->y, pt2->y));
>
> point_above(PG_FUNCTION_ARGS)
> ...
>         PG_RETURN_BOOL(FPgt(pt1->y, pt2->y));
>
> So point_below would be more accurately described as "is strictly below",
> so its operator name really ought to be <<|.  And point_above is "is
> strictly above", so its operator name ought to be |>>.

I prepared a patch to add <<| and |>> operators for points to
deprecate the previous ones.

> 3. The box functions do seem to be correctly documented:
>
> box_below_eq(PG_FUNCTION_ARGS)
> ...
>         PG_RETURN_BOOL(FPle(box1->high.y, box2->low.y));
>
> box_above_eq(PG_FUNCTION_ARGS)
> ...
>         PG_RETURN_BOOL(FPge(box1->low.y, box2->high.y));
>
> But there are comments in the source code to the effect of
>
>  * box_below_eq and box_above_eq are obsolete versions that (probably
>  * erroneously) accept the equal-boundaries case.  Since these are not
>  * in sync with the box_left and box_right code, they are deprecated and
>  * not supported in the PG 8.1 rtree operator class extension.
>
> I'm not sure how seriously to take this deprecation comment, but it
> is true that box_below (<<|) and box_above (|>>) have analogs for
> other data types while these functions don't.

I think we should take this comment seriously and deprecate those
operators, so the patch removes them from the documentation.

> 4. Just for extra fun, these point operators are listed in some
> GIST and SP-GIST opclasses; though the box ones are not, as per
> that code comment.

It also updates the operator classes to support the new operators
instead of former ones.  I don't think there are many users of them to
notice the change.

I am adding this to the next commitfest.

  5. Re: Bogus documentation for bogus geometric operators

    Michael Paquier <michael@paquier.xyz> — 2020-09-05T01:45:22Z

    On Fri, Aug 21, 2020 at 12:00:45PM +0100, Emre Hasegeli wrote:
> I prepared a patch to add <<| and |>> operators for points to
> deprecate the previous ones.

Emre, the CF bot complains that this does not apply anymore, so please
provide a rebase.  By the way, I am a bit confused to see a patch
that adds new operators on a thread whose subject is about
documentation.
--
Michael

  6. Re: Bogus documentation for bogus geometric operators

    Emre Hasegeli <emre@hasegeli.com> — 2020-09-07T10:50:17Z

    > Emre, the CF bot complains that this does not apply anymore, so please
> provide a rebase.  By the way, I am a bit confused to see a patch
> that adds new operators on a thread whose subject is about
> documentation.

Rebased version is attached.

The subject is about the documentation, but the post reveals
inconsistencies of the operators.  Tom Lane fixed the documentation on
the back branches.  The new patch is to fix the operators on the
master only.

  7. Re: Bogus documentation for bogus geometric operators

    Pavel Borisov <pashkin.elfe@gmail.com> — 2020-11-03T09:30:41Z

    > The subject is about the documentation, but the post reveals
> inconsistencies of the operators.  Tom Lane fixed the documentation on
> the back branches.  The new patch is to fix the operators on the
> master only.
>

Nice catch, thanks!
I agree that different operators should not have the same name and I'm
planning to review the patch soon. What are your ideas on the possibility
to backpatch it also? It seems a little bit weird that the operator can
change its name between versions of PG.
-- 
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

  8. Re: Bogus documentation for bogus geometric operators

    Pavel Borisov <pashkin.elfe@gmail.com> — 2020-11-03T10:53:12Z

     Emre, could you please again rebase your patch on top of
2f70fdb0644c32c4154236c2b5c241bec92eac5e
?
 It is not applied anymore.

>

-- 
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

  9. Re: Bogus documentation for bogus geometric operators

    Pavel Borisov <pashkin.elfe@gmail.com> — 2020-11-04T09:02:52Z

    Emre,

I've rebased and tested your proposed patch. It seems fine and sensible to
me.
I have only one thing to note: as this patch doesn't disable <^ and >^
operator for boxes the existing state of documentation seem consistent to
me:

select '((0,0),(1,1))'::box <<| '((0,1),(1,2))'::box;
----------
 f

select '((0,0),(1,1))'::box <^ '((0,1),(1,2))'::box;
----------
 t

So I've only reverted the changes in the documentation on geometric
functions in your patch.
PFA v3 of your patch. I'd mark it ready to commit if you agree.

Thank you!

-- 
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

  10. Re: Bogus documentation for bogus geometric operators

    Emre Hasegeli <emre@hasegeli.com> — 2020-11-04T09:32:19Z

    > I've rebased and tested your proposed patch. It seems fine and sensible to me.

Thanks

> I have only one thing to note: as this patch doesn't disable <^ and >^ operator for boxes the existing state of documentation seem consistent to me:
>
> select '((0,0),(1,1))'::box <<| '((0,1),(1,2))'::box;
> ----------
>  f
>
> select '((0,0),(1,1))'::box <^ '((0,1),(1,2))'::box;
> ----------
>  t
>
> So I've only reverted the changes in the documentation on geometric functions in your patch.

You are right.  We need to keep the documentation for box operators,
but remove the lines for the point operators.

  11. Re: Bogus documentation for bogus geometric operators

    Pavel Borisov <pashkin.elfe@gmail.com> — 2020-11-04T09:43:18Z

    >
> > I have only one thing to note: as this patch doesn't disable <^ and >^
> operator for boxes the existing state of documentation seem consistent to
> me:
> >
> > select '((0,0),(1,1))'::box <<| '((0,1),(1,2))'::box;
> > ----------
> >  f
> >
> > select '((0,0),(1,1))'::box <^ '((0,1),(1,2))'::box;
> > ----------
> >  t
> >
> > So I've only reverted the changes in the documentation on geometric
> functions in your patch.
>
> You are right.  We need to keep the documentation for box operators,
> but remove the lines for the point operators.
>

Indeed you are right. PFA v4 with documentation removed for <^ and >^ for
point
Thanks!

-- 
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

  12. Re: Bogus documentation for bogus geometric operators

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-11-12T22:16:33Z

    Pavel Borisov <pashkin.elfe@gmail.com> writes:
> [ v4-0001-Deprecate-and-replace-and-operators-for-points.patch ]

I made a cursory pass over this, and two things stood out to me:

1. The patch removes <^ and >^ from func.sgml, which is fine, but
shouldn't there be an addition for the new operators?  (I think
probably this need only be an addition of "point" as a possible
input type for <<| and |>>.)  Actually, as long we're not completely
removing these operators, I'm not sure it's okay to make them completely
undocumented.  Maybe instead of removing, change the text to be
"Deprecated, use the equivalent XXX operator instead."  Or we could
add a footnote similar to what was there for a previous renaming:

	Note

	Before PostgreSQL 8.2, the containment operators @> and <@ were
	respectively called ~ and @. These names are still available, but
	are deprecated and will eventually be removed.

2. I'm a bit queasy about removing these operators from the opclasses.
I'm not sure anyone will thank us for "the operator is still there, so
your query is still accepted, but it runs 1000X slower than before".
It seems like more plausible answers are either "nuke the operators
entirely, force people to change their queries now" or else "support
both old and new names in the opclasses for awhile to come".  In
previous operator renamings we've generally followed the second path,
so that's what I'm inclined to think should happen here.

			regards, tom lane

  13. Re: Bogus documentation for bogus geometric operators

    Pavel Borisov <pashkin.elfe@gmail.com> — 2020-11-13T08:26:53Z

    >
> 1. The patch removes <^ and >^ from func.sgml, which is fine, but

shouldn't there be an addition for the new operators?  (I think
>
I fully agree and added "point" as a possible input type for <<| and |>> in
manual. PFA v5


> undocumented.  Maybe instead of removing, change the text to be
> "Deprecated, use the equivalent XXX operator instead."  Or we could
> add a footnote similar to what was there for a previous renaming:
>
The problem that this new <<| is equivalent to <^ only for points (To
recap: the source of a problem is the same name of <^  operator for points
and boxes with different meaning for these types).

                               point
                                               box
<<| |>>          strictly above/below  (new)
                strictly above/below
<^ >^             strictly above/below (deprecated, but available)
     above/below

So it seems to me that trying to mention the subtle difference of
deprecated operator to same-named one for different data type inevitably
make things much worse for reader. On this reason I'd vote for complete
nuking <^ for point type (but this is not the only way so I haven't done
this in v5).

What do you think?

-- 
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

  14. Re: Bogus documentation for bogus geometric operators

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-11-22T23:52:26Z

    Pavel Borisov <pashkin.elfe@gmail.com> writes:
>> undocumented.  Maybe instead of removing, change the text to be
>> "Deprecated, use the equivalent XXX operator instead."  Or we could
>> add a footnote similar to what was there for a previous renaming:

> The problem that this new <<| is equivalent to <^ only for points (To
> recap: the source of a problem is the same name of <^  operator for points
> and boxes with different meaning for these types).

I don't think it's that hard to be clear; see proposed wording below.

The other loose end is that I don't think we can take away the opclass
entries for the old spellings, unless we're willing to visibly break
people's queries by removing those operator names altogether.  That
doesn't seem like it'll fly when we haven't even deprecated the old
names yet.  So for now, we have to support both names in the opclasses.
I extended the patch to do that.

This version seems committable to me --- any thoughts?

			regards, tom lane

  15. Re: Bogus documentation for bogus geometric operators

    Pavel Borisov <pashkin.elfe@gmail.com> — 2020-11-23T09:09:34Z

    >
> >> undocumented.  Maybe instead of removing, change the text to be
> >> "Deprecated, use the equivalent XXX operator instead."  Or we could
> >> add a footnote similar to what was there for a previous renaming:
>
> > The problem that this new <<| is equivalent to <^ only for points (To
> > recap: the source of a problem is the same name of <^  operator for
> points
> > and boxes with different meaning for these types).
>
> I don't think it's that hard to be clear; see proposed wording below.
>
> The other loose end is that I don't think we can take away the opclass
> entries for the old spellings, unless we're willing to visibly break
> people's queries by removing those operator names altogether.  That
> doesn't seem like it'll fly when we haven't even deprecated the old
> names yet.  So for now, we have to support both names in the opclasses.
> I extended the patch to do that.
>
> This version seems committable to me --- any thoughts?
>
The wording seems no problem to me. I  looked into a patch and changes also
seem sensible but I can not apply this patch because of really many
rejects. Which commit should I use to apply it onto?

-- 
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

  16. Re: Bogus documentation for bogus geometric operators

    Pavel Borisov <pashkin.elfe@gmail.com> — 2020-11-23T09:17:37Z

    >
> The wording seems no problem to me. I  looked into a patch and changes
>> also seem sensible but I can not apply this patch because of really many
>> rejects. Which commit should I use to apply it onto?
>
> Sorry, the rejects were due to my git configuration. I will apply and make
the final checks soon.


-- 
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>

  17. Re: Bogus documentation for bogus geometric operators

    Pavel Borisov <pashkin.elfe@gmail.com> — 2020-11-23T11:44:06Z

    The following review has been posted through the commitfest application:
make installcheck-world:  tested, passed
Implements feature:       tested, passed
Spec compliant:           not tested
Documentation:            tested, passed

I've made another check of the final state and suppose it is ready to be pushed.

Pavel Borisov

  18. Re: Bogus documentation for bogus geometric operators

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-11-23T16:39:29Z

    Pavel Borisov <pashkin.elfe@gmail.com> writes:
> I've made another check of the final state and suppose it is ready to be pushed.

Sounds good, pushed.

			regards, tom lane