On Wed, Jun 1, 2016 at 10:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> As I understand it, the key problem is that tests like "is point on line"
> would basically never succeed except in the most trivial cases, because of
> roundoff error. That's not very nice, and it might cascade to larger
> problems like object-containment tests failing unexpectedly. We would
> need to go through all the geometric operations and figure out where that
> kind of gotcha is significant and what we can do about it. Seems like a
> fair amount of work :-(. If somebody's willing to do that kind of
> investigation, then sure, but I don't think just blindly removing these
> macros is going to lead to anything good.
Yeah, it does seem to need some research.
> Also, I suppose this means that Robert promises not to make any of his
> usual complaints about breaking compatibility? Because we certainly
> would be.
Pot, meet Mr. Kettle!
Obviously, the inconvenience caused by any backward incompatibility
has to be balanced against the fact that the new behavior is
presumably better. But I stridently object to the accusation that of
the two of us I'm the one more concerned with backward-compatibility.
There may be some instances where I've had a more conservative
judgement than you about breaking user-facing stuff, but you've
blocked dozens of changes to the C API that would have enabled
meaningful extension development on the grounds that somebody might
complain when a future release changes the API! I think behavior
changes that users will notice are of vastly greater significance than
those which will only be observed by developers.
In this particular case, I think that the current behavior is pretty
stupid, and that the built-in geometric types are barely used,
possibly because they have stupid behavior. So I would be willing to
bet on a well-thought-out change in this area coming out to a net
positive.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company