Received: from myst.fourpalms.org (golem.fourpalms.org [64.3.68.148])
	by postgresql.org (Postfix) with ESMTP id BABC0475461
	for <pgsql-hackers@postgresql.org>;
	Tue, 16 Jul 2002 11:29:41 -0400 (EDT)
Received: from fourpalms.org (localhost.localdomain [127.0.0.1])
	by myst.fourpalms.org (Postfix) with ESMTP
	id 45703AC280; Tue, 16 Jul 2002 08:29:46 -0700 (PDT)
Message-ID: <3D343BEA.1B51B9CD@fourpalms.org>
Date: Tue, 16 Jul 2002 08:29:46 -0700
From: Thomas Lockhart <lockhart@fourpalms.org>
Organization: PostgreSQL Inc.
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.8-34.1mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Tim Hart <tjhart@mac.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [SQL] line datatype
References: <200207161521.g6GFL5417443@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Archive-Number: 200207/640
X-Sequence-Number: 25014

...
> > 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...

                     - Thomas