Re: [PATCH] Revive line type - Mailing list pgsql-hackers

From Greg Smith
Subject Re: [PATCH] Revive line type
Date
Msg-id 51EDDE00.6040308@2ndQuadrant.com
Whole thread Raw
In response to Re: [PATCH] Revive line type  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On 6/26/13 9:34 PM, Peter Eisentraut wrote:
> Still wondering whether to use a A,B,C-based output
> format per Tom's comment.

Wouldn't it also be helpful to remove "The points used in the output are 
not necessarily the points used on input" by making that not true?

There are three obvious ways you might output a line:

-Math class expectations of slope-intercept form:  y = mx + b. 
Intercept forms don't handle both horizontal and vertical lines though, 
so that's easily out.

-Pair of points.  A casual observer might get lucky and observe putting 
a pair of points in and getting the same pair back again, then 
incorrectly assume that's normally the case.  Seems better to never make 
that possible in the infinite line case.  I'm reminded of how row output 
usually is in order gives a bad impression about ordering guarantees in SQL.

-Ax+By+C=0

Outputting that third one, when it's also the internal form, handles any 
time of line; will show any assumptions about individual points being 
preserved are wrong; and avoids rounding errors too.  The only downside 
seems to be that bounded lines are easier to show with a pair of points.  I think that suggests an alternate, secondary
outputformat would be 
 
useful though, rather than that a different default one is a good idea.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)
Next
From: Noah Misch
Date:
Subject: Re: Preventing tuple-table leakage in plpgsql