Re: New Defects reported by Coverity Scan for PostgreSQL

Tomas Vondra <tomas.vondra@2ndquadrant.com>

From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: emre@hasegeli.com, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ning Yu <nyu@pivotal.io>, Alvaro Herrera <alvherre@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-08-01T13:33:47Z
Lists: pgsql-hackers

On 08/01/2018 11:55 AM, Emre Hasegeli wrote:
>> Or perhaps I have it backwards and "l1" and "l2" need to be swapped in
>> that description.  But the mere fact that there is any question about
>> that means that the function is poorly documented and perhaps poorly
>> named as well.  For that matter, is there a good reason why l1/l2
>> have those roles and not the reverse?
> 
> Consistency.  I organized all xxx_closept_yyy(Point *result, xxx *l1,
> yyy *l2) functions in a way that they find the find the point on "l1".
> 

IMHO the main issue here is that the rule is not obvious / documented 
anywhere. I think the best way to do that is by making it clear in a 
comment for each such such function.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Commits

  1. geo_ops.c: Clarify comments and function arguments

  2. Refactor geometric functions and operators