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
-
geo_ops.c: Clarify comments and function arguments
- 74514bd4a58d 12.0 landed
-
Refactor geometric functions and operators
- a7dc63d904a6 12.0 cited