Re: [SQL] line datatype

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: Thomas Lockhart <lockhart(at)fourpalms(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tim Hart <tjhart(at)mac(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [SQL] line datatype
Date: 2002-07-16 16:26:49
Message-ID: 200207161626.g6GGQnk01519@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

Lamar Owen wrote:
> On Tuesday 16 July 2002 11:29 am, Thomas Lockhart wrote:
> > > > We do need a solution for exact dump/reload of floating-point data,
> > > > but I don't see why the lack of it should be reason to disable access
> > > > to the LINE type.
>
> > > I don't understand why dumping the two point values isn't sufficient.
>
> > Which two point values? LINE is handled as an equation, not as points,
> > unlike the LSEG type which has two points.
>
> > One possibility is to have the external representation *be* the same as
> > LSEG, then convert internally. Then we need to decide how to scale those
> > points; maybe always using a unit vector is the right thing to do...
>
> Lines are entered now by specifying two points, anywhere on the line, right?
> The internal representation is then slope-intercept? Why not allow either
> the 'two-point' entry, or direct entry as slope-intercept? How do we
> represent lines now in output? Do we pick two arbitrary points on the line?
> If so, I can see Thomas' point here, where the original data entry might have
> specified two relatively distant points -- but then there's a precision error
> anyway converting to slope-intercept, if indeed that is the internal
> representation. So why not dump in slope-intercept form, if that is the
> internal representation?

Yow, I can see the pain of having slope/intercept and trying to output
two points. What if we store line internally as two points, and convert
to slope/intercept when needed. That way, it would dump out just as it
was entered.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-07-16 16:30:27 Re: [SQL] line datatype
Previous Message Tom Lane 2002-07-16 16:23:01 OID suppression issues

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2002-07-16 16:30:27 Re: [SQL] line datatype
Previous Message Stephan Szabo 2002-07-16 16:11:13 Re: Cascading deletions does not seem to work inside PL/PGSQL