Re: [HACKERS] [PATCH] Improve geometric types

2017-11-09 Thread Emre Hasegeli
>> This is also effecting lseg ## box operator. > > Mmm.. It returns (1.5, 1.5) with the 0004 patch. It is surely a > point on the second operand but I'm not sure it's right that the > operator returns a specific point for two parallel segments. I am changing it to return NULL, when they are

Re: [HACKERS] [PATCH] Improve geometric types

2017-11-09 Thread Kyotaro HORIGUCHI
Hello, > I'd like to put comments on 0001 and 0004 only now: ... I don't have a comment on 0002. About 0003: > @@ -4487,21 +4486,21 @@ circle_in(PG_FUNCTION_ARGS) > ... > circle->radius = single_decode(s, , "circle", str); > - if (circle->radius < 0) > + if

Re: [HACKERS] [PATCH] Improve geometric types

2017-11-07 Thread Kyotaro HORIGUCHI
Hello, thanks for the new patch. 0004 failed to be applied on the underneath patches. At Sun, 5 Nov 2017 15:54:19 +0100, Emre Hasegeli wrote in > > I am not sure how useful NaNs are in geometric types

Re: [HACKERS] [PATCH] Improve geometric types

2017-10-04 Thread Emre Hasegeli
> Now, it's also not clear that anything in PG really cares. But if we > do care, I think we should keep pg_hypot() ... and maybe clarify the > comment a bit more. I am not sure how useful NaNs are in geometric types context, but we allow them, so inconsistent hypot() would be a problem. I will

Re: [HACKERS] [PATCH] Improve geometric types

2017-10-03 Thread Tom Lane
Emre Hasegeli writes: >> Uh, I thought pg_hypot() was still needed on our oldest supported >> platforms. Or is hypot() already supported there? > What is our oldest supported platform? Our normal reference for such questions is SUS v2 (POSIX 1997):

Re: [HACKERS] [PATCH] Improve geometric types

2017-10-03 Thread Emre Hasegeli
> Uh, I thought pg_hypot() was still needed on our oldest supported > platforms. Or is hypot() already supported there? If not, I suppose we > can keep the HYPOT() macro, and have it use hypot() on platforms that > have it and pg_hypot elsewhere? That particular fraction of 0001 seemed > a bit

Re: [HACKERS] [PATCH] Improve geometric types

2017-10-03 Thread Emre Hasegeli
> I think if we're going to do this it should be separated out as its > own patch. Also, I think someone should explain what the reasoning > behind the change is. Do we, for example, foresee that the built-in > code might be faster or less likely to overflow? Because we're > clearly taking a

Re: [HACKERS] [PATCH] Improve geometric types

2017-10-03 Thread Alvaro Herrera
Robert Haas wrote: > I'm potentially willing to commit a patch that just makes the > pg_hypot() -> hypot() change and does nothing else, if there are not > objections to that change, but I want to be sure that we'll know right > away if that turns out to break. Uh, I thought pg_hypot() was still

Re: [HACKERS] [PATCH] Improve geometric types

2017-10-03 Thread Kyotaro HORIGUCHI
At Mon, 2 Oct 2017 08:23:49 -0400, Robert Haas wrote in > On Mon, Oct 2, 2017 at 4:23 AM, Kyotaro HORIGUCHI > wrote: > > For other potential reviewers: > > > > I found

Re: [HACKERS] [PATCH] Improve geometric types

2017-10-03 Thread Kyotaro HORIGUCHI
Thanks. At Mon, 2 Oct 2017 11:46:15 +0200, Emre Hasegeli wrote in

Re: [HACKERS] [PATCH] Improve geometric types

2017-10-02 Thread Robert Haas
On Mon, Oct 2, 2017 at 4:23 AM, Kyotaro HORIGUCHI wrote: > For other potential reviewers: > > I found the origin of the function here. > > https://www.postgresql.org/message-id/4a90bd76.7070...@netspace.net.au >

Re: [HACKERS] [PATCH] Improve geometric types

2017-10-02 Thread Kyotaro HORIGUCHI
Hello. Thank you for the new version. 0001: applies cleanly. regress passed. this mainly refactoring geo_ops.c and replacing pg_hypot with hypot(3). 0002: applies cleanly. regress passed. this just replaces float-ops macros into inline functions. 0003: applies cleanly. regress passed.

Re: [HACKERS] [PATCH] Improve geometric types

2017-09-27 Thread Emre Hasegeli
> The patch replace pg_hypot with hypot in libc. The man page says > as follows. > > man 3 hypot >> If the result overflows, a range error occurs, and the functions return >> HUGE_VAL, HUGE_VALF, or HUGE_VALL, respectively. > .. >>ERRORS >> See math_error(7) for information on

Re: [HACKERS] [PATCH] Improve geometric types

2017-09-19 Thread Kyotaro HORIGUCHI
At Fri, 15 Sep 2017 11:25:30 -0400, Robert Haas wrote in > On Fri, Sep 15, 2017 at 4:23 AM, Kyotaro HORIGUCHI > wrote: > > /* don't merge the following same functions

Re: [HACKERS] [PATCH] Improve geometric types

2017-09-15 Thread Robert Haas
On Fri, Sep 15, 2017 at 4:23 AM, Kyotaro HORIGUCHI wrote: > /* don't merge the following same functions with different types >into single macros so that double evaluation won't happen */ > > Is it still too verbose? Personally, I don't think such a comment

Re: [HACKERS] [PATCH] Improve geometric types

2017-09-15 Thread Kyotaro HORIGUCHI
Hello, just one point on 0001. The patch replace pg_hypot with hypot in libc. The man page says as follows. man 3 hypot > If the result overflows, a range error occurs, and the functions return > HUGE_VAL, HUGE_VALF, or HUGE_VALL, respectively. .. >ERRORS > See math_error(7)

Re: [HACKERS] [PATCH] Improve geometric types

2017-09-15 Thread Kyotaro HORIGUCHI
At Fri, 15 Sep 2017 17:23:28 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170915.172328.97446299.horiguchi.kyot...@lab.ntt.co.jp> > At Thu, 14 Sep 2017 16:19:13 -0400, Robert Haas wrote > in

Re: [HACKERS] [PATCH] Improve geometric types

2017-09-15 Thread Kyotaro HORIGUCHI
At Thu, 14 Sep 2017 16:19:13 -0400, Robert Haas wrote in > On Thu, Sep 14, 2017 at 3:33 AM, Kyotaro HORIGUCHI > wrote: > > I recall a bit about the double-evaluation

Re: [HACKERS] [PATCH] Improve geometric types

2017-09-14 Thread Robert Haas
On Thu, Sep 14, 2017 at 3:33 AM, Kyotaro HORIGUCHI wrote: > I recall a bit about the double-evaluation hazards. I think the > functions needs a comment describing the reasons so that anyone > kind won't try to merge them into a macro again. I think we can count

Re: [HACKERS] [PATCH] Improve geometric types

2017-09-14 Thread Kyotaro HORIGUCHI
At Tue, 12 Sep 2017 19:30:44 +0200, Emre Hasegeli wrote in

Re: [HACKERS] [PATCH] Improve geometric types

2017-09-12 Thread Emre Hasegeli
> Hello, sorry to late for the party, but may I comment on this? Thank you for picking this up again. > The first patch reconstructs the operators in layers. These > functions are called very frequently when used. Some function are > already inlined in float.h but some static functions in

Re: [HACKERS] [PATCH] Improve geometric types

2017-09-12 Thread Kyotaro HORIGUCHI
Hello, sorry to late for the party, but may I comment on this? At Tue, 05 Sep 2017 13:18:12 +, Aleksander Alekseev wrote in <20170905131812.18925.13551.p...@coridan.postgresql.org> > The following review has been posted through the commitfest application: > make

Re: [HACKERS] [PATCH] Improve geometric types

2017-09-05 Thread Aleksander Alekseev
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed LGTM. The new status of this patch is: Ready for Committer

Re: [HACKERS] [PATCH] Improve geometric types

2017-09-04 Thread Aleksander Alekseev
The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: not tested Spec compliant: not tested Documentation:not tested PostgreSQL fails with SIGSEGV during `make check-world`. Backtrace:

Re: [HACKERS] [PATCH] Improve geometric types

2017-09-01 Thread Aleksander Alekseev
The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested Hi Emre, I'm afraid these patches conflict with current master branch. The