pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Lamar Owen <lamar.owen@wgcr.org>
Cc: Thomas Lockhart <lockhart@fourpalms.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tim Hart <tjhart@mac.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [SQL] line datatype
Date: Tue, 16 Jul 2002 12:26:49 -0400 (EDT)
Message-ID: <200207161626.g6GGQnk01519@candle.pha.pa.us> (raw)
In-Reply-To: <200207161210.23948.lamar.owen@wgcr.org>

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@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026



view thread (16+ messages)  latest in thread

Message-ID: <200207161626.g6GGQnk01519@candle.pha.pa.us>
Permalink:  ../200207161626.g6GGQnk01519@candle.pha.pa.us/
Also on:    postgresql.org/message-id/200207161626.g6GGQnk01519@candle.pha.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-sql@postgresql.org
  Cc: pgman@candle.pha.pa.us, lamar.owen@wgcr.org, lockhart@fourpalms.org, tgl@sss.pgh.pa.us, tjhart@mac.com, pgsql-hackers@postgresql.org
  Subject: Re: [SQL] line datatype
  In-Reply-To: <200207161626.g6GGQnk01519@candle.pha.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox