From: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] [PATCH] Improve geometric types |
Date: | 2018-01-17 17:59:30 |
Message-ID: | CAE2gYzzgJ7B-HdmxuSDoqu-_x1nEeoEA45is2hP8ex4r3KNH8Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I'm not sure what you mean by the "basic comparison ops" but I'm
> fine with the policy, handling each component values in the same
> way with float. So point_eq_point() is right and other functions
> should follow the same policy.
I mean <, >, <= and >= by basic comparison operators. Operators with
those symbols are available for some geometric types, but they are
comparing the sizes of the objects. Currently only the equality
operators follow the same policy with point_eq_point (), others never
return true when NaNs are involved.
> Sorry for going back and force, but I don't see a difference
> between it and the original behavior from the point of view of
> reasonability. Isn't is enough to let each component comparison
> follow float by redefining FPxx() functions?
My previous patch was doing exactly that. I though that is not what
we want to do. Do we want box_overlap() to return true when NaNs are
involved?
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-01-17 18:06:31 | Re: Is there a "right" way to test if a database is empty? |
Previous Message | Peter Eisentraut | 2018-01-17 17:50:35 | Re: [HACKERS] GnuTLS support |