>> 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 paral
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, &s, "circle", str);
> - if (circle->radius < 0)
> + if (float8_lt(circle->r
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 context, but we
> > allow them, so inconsistent hypot() would be a problem. I will change
>
> 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
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):
http://pubs.opengroup.org/onlinepubs/007908799
> 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 d
> 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 ris
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
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 the origin of the function here.
> >
> > https://www.postgresql.org/message-id/4a90bd76.7070...@netspace.net.au
> > https://www
Thanks.
At Mon, 2 Oct 2017 11:46:15 +0200, Emre Hasegeli wrote in
> > And this should be the last comment of mine on the patch set.
>
> Thank you. The new versions of the patches are attached addressing
> your comments.
>
> > By the way, I found that MAXDOUBLEWIDTH has two inconsistent
> > d
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
> https://www.postgresql.org/message-id/AANLkTim4cHELcGPf5w7Zd43_dQi_2RJ_b5_F_idSSbZI%40
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.
> 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 how
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 with different types
> >into single macros so that double evaluation won't happen */
> >
> > Is it still too verbose?
>
> P
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 has much value, but I am not
going t
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) for
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
> > On Thu, Sep 14, 2017 at 3:33 AM, Kyotaro HORIGUCHI
> > wrote:
> > > I recall a bit
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 hazards. I think the
> > functions needs a comment describing the reasons so that anyone
> > kind won't try to merge them into a
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 on PostgreSQL developers to underst
At Tue, 12 Sep 2017 19:30:44 +0200, Emre Hasegeli wrote in
> > 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 func
> 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 float.h
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 installcheck-world: tested,
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
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: http
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
25 matches
Mail list logo
